Роботы Яндекса
Методы управления поведением робота Яндекса
Виды роботов Яндекса
IP-адреса роботов Яндекса
IP-адресов, с которых «ходит» робот Яндекса, много, и они могут меняться. Список адресов не разглашается.
Кроме роботов у Яндекса есть несколько агентов-«простукивалок», которые определяют, доступен ли в данный момент сайт или документ, на который стоит ссылка в соответствующем сервисе.
Директива Host
Во избежания возникновения проблем с зеркалами сайта рекомендуется использовать директиву «Host». Директива «Host» указывает роботу Яндекса на главное зеркало данного сайта. С директивой «Disallow» никак не связана.
User-agent: Yandex
Disallow: /cgi-bin
Host: www.site.ru
User-agent: Yandex
Disallow: /cgi-bin
Host: site.ru
в зависимости от того что для вас оптимальнее.
Вот цитата из ЧаВо Яндекса:
Мой сайт показывается в результатах поиска не под тем именем. Как это исправить?
Скорее всего, ваш сайт имеет несколько зеркал, и робот выбрал как основное не то зеркало, которое хочется вам. Есть несколько решений:
В случае реализации одного из вышеперечисленных советов ваше основное зеркало будет автоматически изменено по мере обхода робота.
Интересная информация об обработке директивы Host из ответов А. Садовского на вопросы оптимизаторов:
Вопрос: Когда планируется своевременное соблюдение директивы Host: в robots.txt? Если сайт индексируется как www.site.ru, когда указано Host: site.ru уже после того, как robots.txt был размещен 1–2 недели, то при этом сайт с www и без www не склеивается более 1–2 месяца и в Яндексе существуют одновременно 2 копии частично пересекающихся сайтов (один 550 страниц, другой 150 страниц, при этом 50 страниц одинаковых). Прокомментируйте, пожалуйста, проблемы с работой «зеркальщика».
Ответ: Расширение стандарта robots.txt, введенное Яндексом, директива Host — это не команда считать зеркалами два любых сайта, это указание, какой сайт из группы, определенных автоматически как зеркала, считать главным. Следовательно, когда сайты будут идентифицированы как зеркала, директива Host сработает.
HTML-тег
Тег работает аналогично мета-тегу noindex, но распространяется только на контент, заключенный внутри тега в формате:
текст, индексирование которого нужно запретить
Тег noindex не чувствителен к вложенности (может находиться в любом месте html-кода страницы). При необходимости сделать код сайта валидным возможно использование тега в следующем формате:
текст, индексирование которого нужно запретить
Ip адреса ботов яндекса
Коллеги, подскажите пожалуйста где добыть список ip-адресов с которых ходят боты яндекса?
А так же по возможности
Google, Mail, Rambler, Bing, Ask и др.
Спасибо, а как быть с другими ПС?
IPGrabber is the world’s largest database of verified search engine spiders.
IPGrabber is the world’s largest database of verified search engine spiders.
alexvivarina:
Коллеги, подскажите пожалуйста где добыть список ip-адресов с которых ходят боты яндекса?
А так же по возможности
Google, Mail, Rambler, Bing, Ask и др.
IP-адреса, которые использует робот Googlebot, время от времени меняются. Чтобы узнать, посещал ли он ваш сайт, просмотрите данные по агенту пользователя (Googlebot). С помощью обратного DNS-запроса можно проверить, действительно ли к вашему серверу обращался Googlebot, а не другой робот.
Вы можете убедиться, что ваш сайт сканирует робот Googlebot или иной поисковый робот Google. Это полезно сделать, если у вас есть подозрения, что под видом робота Googlebot к вашему сайту обращаются спамеры или другие злоумышленники. Компания Google не публикует «белые списки» IP-адресов для веб-мастеров. Они могут изменяться, что вызовет проблемы на сайтах, где эти адреса указаны в коде. Поэтому мы рекомендуем выполнить DNS-запрос следующим образом:
Как убедиться, что сайт сканируется роботом Googlebot:
С помощью команды host выполните обратный DNS-запрос IP-адреса, который можно узнать в журнале.
Убедитесь, что доменное имя – googlebot.com или google.com.
С помощью команды host выполните прямой запрос DNS на преобразование доменного имени, которое вы узнали на шаге 1. IP-адрес, полученный в результате, и исходный должны совпадать.
Ботнет Mēris: расследуем крупнейшую DDoS-атаку в истории интернета
На днях в СМИ появилась информация о DDoS-атаке на Яндекс. Это правда, но не вся. Нашим специалистам действительно удалось отразить рекордную атаку более чем в 20 млн RPS — это самая крупная атака из известных за всю историю интернета. Но это лишь одна из множества атак, направленных не только на Яндекс, но и на многие другие компании в мире. Атаки продолжаются уже несколько недель, их масштабы беспрецедентны, а их источник – новый ботнет, о котором пока мало что известно.
Сегодня вместе с коллегами из Qrator Labs мы хотим поделиться текущими результатами совместного расследования деятельности нового ботнета Mēris. Расследование еще продолжается, но мы считаем важным поделиться уже собранной информацией со всей индустрией.
В конце июня 2021 года и мы в Яндексе, и наши коллеги из Qrator Labs начали замечать признаки новой атакующей силы в глобальной сети – ботнета нового типа. Обнаруженный ботнет уже тогда обладал значительными масштабами – десятки тысяч устройств, но их количество быстро растет и сейчас. Qrator Labs наблюдали 30 000 хостов в отдельных атаках, мы в Яндексе собрали данные о 56 000 атакующих устройств. Но мы предполагаем, что истинное количество значительно больше – вероятно, более 200 000 устройств. Полная сила ботнета не видна из-за ротации устройств и отсутствия у атакующих желания показывать всю имеющуюся мощность. Более того, устройства в ботнете являются высокопроизводительными, а не типичными девайсами «интернета вещей», подключенными к сети Wi-Fi. С наибольшей вероятностью ботнет состоит из девайсов, подключенных через Ethernet-соединение, – в основном, сетевых устройств.
Некоторые организации уже окрестили этот ботнет «вернувшимся Mirai». Но мы не считаем такое определение в достаточной степени точным. Mirai обладал большим количеством зараженных устройств, объединенных под управлением единого командного центра, и атаковал он, в первую очередь, трафиком сетевого уровня.
У нас еще не было возможности изучить пример вредоносного кода, который используется для заражения новых устройств данного ботнета, и мы не готовы утверждать, относится он к семейству Mirai или нет. Пока считаем, что нет, поскольку устройства, объединенные под единым командным центром, похоже, относятся только к производителю Mikrotik.
Это и есть причина, по которой мы хотели дать другое имя новому ботнету, работающему под еще не пойманным командным центром. Коллеги из Qrator Labs выбрали Mēris – по-латышски «чума». Такое название кажется уместным и относительно близким к Mirai по произношению.
Еще один достаточно очевидный момент – ботнет продолжает расти. У нас есть предположение, что он может разрастаться за счет техники брутфорса (перебора паролей), хотя этот вариант не кажется основным. Вся ситуация больше указывает на то, что уязвимость либо хранилась в секрете до начала полномасштабной кампании, либо была продана на черном рынке.
В наши задачи не входит исследование первопричин и поиск виновных – сосредоточимся на дальнейших наблюдениях.
В последние пару недель все мы стали свидетелями разрушительных DDoS-атак в Новой Зеландии, США и России. Все эти атаки мы ассоциируем с ботнетом Mēris. В настоящий момент он может перегрузить практически любую сетевую инфраструктуру, включая некоторые сети высокой надежности, специально созданные, чтобы выдерживать подобную нагрузку. Главный признак ботнета – чудовищный показатель RPS.
Cloudflare была первой компанией, которая публично рассказала об атаках подобного масштаба. В посте в блоге от 19 августа они упоминали об атаке, достигшей 17 млн запросов в секунду. Мы сообщили Cloudflare, что в сентябре наблюдали схожую картину по продолжительности и распределению стран-источников.
График RPS DDoS-атаки на Яндекс 5 сентября 2021 года
Яндекс стал одной из компаний, испытавших на себе возможности ботнета Mēris. К счастью, наша техническая команда смогла нейтрализовать атаку и предотвратить отказ в обслуживании. Атака не повлияла на работу сервисов, и данные пользователей не пострадали. Хотя цифры все еще ошеломляют – почти 21,8 млн RPS. Это крупнейшая в истории зарегистрированная атака на уровне приложения (L7 DDoS attack).
А вот статистика роста масштаба атак ботнета Mēris на нас:
7 августа – 5,2 млн RPS
9 августа – 6,5 млн RPS
29 августа – 9,6 млн RPS
31 августа – 10,9 млн RPS
5 сентября – 21,8 млн RPS
Службе информационной безопасности Яндекса удалось установить детали внутреннего устройства ботнета. Для взаимодействия внутри сети используются обратные L2TP-туннели, а количество зараженных устройств достигает 250 000.
Как именно Яндекс выдержал такое огромное количество запросов в секунду?
В Яндексе входящий трафик пользователей проходит через несколько инфраструктурных компонентов, работающих на разных уровнях модели ISO/OSI. Первые компоненты защищают Яндекс от SYN-флуд-атак. Следующие слои анализируют входящий трафик в режиме реального времени. На основе технических сигналов и других статистик система оценивает подозрительность каждого запроса. Наш приоритет – выдать ответ живым пользователям даже в момент DDoS-атаки. Благодаря устройству нашей инфраструктуры мы быстро горизонтально отмасштабировали наши компоненты уже после первых атак и смогли выдержать более мощные волны, не переключаясь в режим бана по IP.
Источники атак (IP-адреса), которые в данном случае не подменяются (не спуфятся), по всей видимости похожи в том, что у них открыты порты 2000 и 5678. Конечно, многие производители устройств размещают на этих портах собственные сервисы. Однако конкретная комбинация порта 2000 с «Bandwidth test server» и порта 5678 с «Mikrotik Neighbor Discovery Protocol» почти не оставляет почвы для сомнений в наших выводах. Хотя Mikrotik использует UDP для своего стандартного сервиса на порту 5678, на скомпрометированных устройствах обнаруживается открытый TCP-порт. Такая маскировка может быть одной из причин того, что владельцы зараженных устройств не замечали их странного поведения.
Основываясь на этом, мы решили проверить TCP-порт 5678 с помощью Qrator.Radar. Полученные нами данные удивляют и пугают одновременно.
Глобальное распределение открытых портов 5678: чем темнее цвет, тем больше устройств
Оказывается, в глобальной сети существует 328 723 активных хоста, отвечающих на запросы пробы по TCP на порту 5678. Конечно, не обязательно каждый из них – это уязвимый Mikrotik. Есть данные о том, что устройства Linksys тоже используют внутренний TCP-сервис на порту 5678. Возможно, Mikrotik и Linksys не единственные, но у нас нет другого выбора, кроме как предположить, что 328 723 – это и есть число хостов в активном ботнете.
Важно, что открытый порт 2000 отвечает на входящее соединение цифровой подписью \x01\x00\x00\x00, которая принадлежит протоколу RouterOS. Поэтому мы считаем, что это не случайный сервер для тестирования пропускной способности, а вполне идентифицируемый.
Цитируя неофициальное описание протокола на GitHub:
Официального описания нет, поэтому все было получено с помощью инструмента WireShark и RouterOS 6, запущенной в виртуальной машине, которая подключалась к реальному устройству. (. )
Установив TCP-соединение с портом 2000, сервер всегда сначала посылает команду «hello» (01:00:00:00). Если в клиенте указан протокол UDP, TCP-соединение все еще устанавливается.
По нашим наблюдениям, 65% атакующих устройств открывают SOCKS4-прокси на порту 5678, а 90-95% открывают Bandwidth test на порту 2000.
Топ стран с источниками ботнета Mēris в рекордной атаке на Яндекс
Использование конвейерной обработки HTTP (так это обозначается в HTTP/1.1, а в HTTP/2 это «мультиплексирование») делает нейтрализацию подобных атак давно забытой задачей. Дело в том, что сетевые устройства обычно установлены у легитимных пользователей. Невозможно быть уверенным, что конечная точка полностью скомпрометирована, превращена в «бота-зомби» и что в трафике атаки не занята лишь часть полосы (а остальная используется в безобидном трафике живого пользователя). В конце концов, на каком-то ресурсе могут быть зарегистрированы пользователи, пытающиеся попасть на него, даже используя скомпрометированные устройства.
Поскольку конвейерная обработка заставляет принимающий сервер отвечать на целый пакет мусорных запросов от одного источника, значит, оптимизация фронтенда может нанести еще больший ущерб при попытке ответить на каждый входящий запрос. И мы говорим об HTTP-запросах, на которые тратится бóльшая часть используемой вычислительной мощности сервера (тем более при защищенном соединении, когда к обработке незашифрованных запросов добавляется криптографическая нагрузка).
Конвейерная обработка – основной источник проблем для всех, кто встретит этот ботнет на своей инфраструктуре. Хотя браузеры (за исключением Pale Moon) в основном не используют конвейерную обработку, боты это делают, и с большим удовольствием. Такие запросы легко распознать и нейтрализовать, ведь все-таки общепринятый в интернете консенсус относительно обработки запросов выглядит как «запрос – ответ», а не как «запрос – запрос – запрос – запрос – ответ».
Сейчас мы наблюдаем реализацию стратегии «качество против количества». Из-за конвейерной обработки запросов злоумышленники могут выжать гораздо больше запросов в секунду по сравнению с «обычными» ботнетами. В том числе – потому, что классические методы нейтрализации попытаются заблокировать атакующий IP-адрес. Однако порядка 10-20 запросов, оставшихся в буферах, будут обработаны даже после этого.
Что делать в такой ситуации?
Черные списки все еще работают. Поскольку в этих атаках не происходит подмены IP-адреса источника (нет спуфинга, как мы уже упомянули), каждая жертва видит источник атаки таким, какой он есть на самом деле. Блокировки на короткий промежуток времени должно быть достаточно, чтобы предотвратить атаку и не побеспокоить конечного пользователя.
Неясно, как владельцы ботнета будут действовать в будущем. Они могут воспользоваться скомпрометированными устройствами полностью, в попытке использовать 100% доступной мощности (и по пропускной, и по вычислительной способности). Тогда не останется другого способа, кроме как блокировать каждый запрос, следующий за первым от одного источника, предотвращая обработку запросов в пайплайне.
Если на целевом сервере отсутствует защита от DDoS-атак, то не только конвейерная обработка запросов может стать катастрофой, поскольку злоумышленнику потребуется гораздо меньше «рабочей силы», чтобы заполнить порог RPS жертвы. Оказалось, очень многие не были готовы к подобному сценарию.
Вчера нам удалось связаться с Mikrotik и предоставить им собранные данные. Кроме того, мы направили всю собранную информацию в профильные организации. Надеемся, что совместные усилия позволят интернету вскоре избавиться от пандемии этой «чумы».
Боты в Метрике: как остановить накрутку ПФ
Наверняка в сводках Яндекс Метрики вы наблюдали печальную картинку в виде множества переходов из социальных сетей, прямой закладочный трафик или мощный трафик из Яндекса или Google (другой поисковой системы) по определенным ключевым запросам. Такой трафик может идти на главную страницу домена или на отдельные страницы (как правило трафиковые, занимающие определенные позиции в TOP). Вначале вы радуетесь, что у вас вырос трафик (все переходы на ваш сайт выглядят вполне естественными), но уже вскоре начинаете понимать (когда переходы становятся не логичными), что-то здесь не так. Это накрутка ПФ (поведенческих факторов): возрастают отказы, падает время пребывания на страницах, доля трафика из соцсетей превышает какой-либо другой. Вне зависимости: выросли на вашем сайте позиции/трафик или просели, метрика резко теряет актуальность данных и превращается в бессмысленный инструмент!
Что это такое? Откуда и почему это появилось на вашем сайте? Что говорит по этому поводу Яндекс? Но самое главное: чем это чревато для сайта и как бороться с этими ботами? Эти вопросы во множестве задаются на форумах и чатах, где каждый волен высказать свою точку зрения, опираясь на собственные наблюдения. Это не новая проблема, однако в последнее время она достигла такого апогея, что дальнейшее развитие событий не может быть проигнорировано Яндексом и требуется кардинальное вмешательство в систему фильтрации трафика.
Пример накрученной метрики коммерческой тематики (лидирует доля прямых заходов и переходов из социальных сетей)
Данное печальное явление мне известно уже больше года, с каждым днем я наблюдаю его на все большем числе сайтов (подвергаются бомбардировке не только коммерческие темы, но и новостники, блоги. любые сайты, которые занимают мало-мальские позиции в поиске). С наступлением 2021 года это уже становится практически повсеместным явлением. В моем кабинете Яндекс Метрики около 300 сайтов, почти у 80% из них есть паразитный трафик.
В то время, как одни сайтовладельцы ищут защиту от такого вида атак, другие во всю зарабатывают на этом, продавая налево и направо паразитный трафик. Одни продают его для «улучшения поведенческих факторов на сайте за счет увеличения времени пребывания на сайте, увеличения глубины просмотра страниц и уменьшения процента отказов«, а другие наоборот для «понижения поведенческих факторов на сайте за счет уменьшения времени пребывания на сайте, уменьшения глубины просмотра страниц и увеличения процента отказов«! Есть спрос и на тех и на других!
Яндекс настолько серьезно подошел к ранжированию сайтов в поисковой выдаче за счет поведенческих факторов (сведя ссылочное к минимуму), что пожалуй, наступило бесповоротное время со всей серьезностью решать вопрос накрутки этих поведенческих факторов. Поскольку масштабы уже зашкаливают все допустимые нормы и правила. Осознают ли проблему в самом Яндексе? Пока же отписка на все вопросы касательно всех этих накруток ПФ стандартная:
Стандартный ответ Яндекса по поводу накрутки ПФ:
В настоящий момент Метрика способна распознать и отфильтровать большую часть существующих роботов, но, учитывая логику работы системы фильтрации, мы не можем гарантировать, что посещения абсолютно всех роботов будут отфильтрованы. По этой причине некоторые переходы роботов могут отображаться в отчетах как визиты обычных посетителей.
Сервис Яндекс.Метрика постоянно развивается, в будущем мы планируем усовершенствовать работу нашей системы фильтрации.
Также обращаем ваше внимание, что счетчик Метрики только фиксирует информацию о визитах, совершаемых на ваш сайт. Мы не располагаем дополнительной информацией о трафике, сверх той, что уже отражена в отчетах, а также не можем каким-либо образом повлиять на него.
Поскольку информация об индексировании сайта и о факторах, влияющих на его ранжирование, является конфиденциальной, поддержка сервиса сможет ответить на запрос только если именно вы заполните форму https://yandex.ru/support/. с логина, на котором подтверждены права на ваш сайт.
При возникновении дополнительных вопросов, пожалуйста, обращайтесь. Мы будем рады помочь.
Между тем, одни жалуются, что теряют трафик и позиции в поиске в результате таких целенаправленных атак конкурентов. Другие жалуются, что метрика утратила всякую достоверность, теперь статистика не различает живых людей и ботов, цифры стали не актуальны, какой прок вообще в их накоплении? Третьи всерьез опасаются «фильтра за накрутку ПФ» (ведь непонятно: как именно поисковая система различает накрутку поведенческих факторов и как накладывает санкции) в то время, как сам Яндекс успокаивает, что нет причин для беспокойства! Ситуация, мягко говоря, зашла в тупик!
Вся проблема в том, что уровень технических возможностей накрутчиков вырос, а алгоритмы фильтрации Яндекс Метрики практически не изменились. Теперь на счетчик Яндекса может влиять каждый школьник для формирования любой требуемой картинки.
Зачем и как накручивают поведенческие факторы
С момента изобретения поведенческих факторов и их учета в ранжировании сайтов в поиске, появились и постепенно эволюционировали методы их накрутки. Сервисы типа Useraror, Movebo, SERPClick, Seopult, WebEffector и т.д. до сих пор продают накрутку поведенческого фактора, в то время, как Яндекс многократно заявлял, что все накрутки «палятся», ссылаясь, что алгоритмы способны самостоятельно отличать сессию заинтересованного пользователя от сессии накрученной ботами.
Вот что говорит о значимости для продвижения поведенческих факторов SEO-словарь «promopult.ru»:
Поведенческие факторы чрезвычайно важны для ранжирования в «Яндексе» — если у сайта плохие пользовательские метрики, он имеет мало шансов на высокие места в выдаче по конкурентным запросам. Наряду с отслеживанием действий реальных пользователей «Яндекс» придает большое значение и мнению асессоров — специалистов, которые анализируют сайт по комплексу параметров и оценивают общее впечатление. Для «Гугла» ПФ имеют намного меньшее значение, однако точно известно, что он учитывает некоторые факторы при оценке релевантности страницы запросу.
Методы воздействия на ПФ постоянно усложнялись, видоизменялись, проводились многочисленные эксперименты, призванные доказать, что на ПФ можно и нужно влиять. Сегодня таких накрутчиков развелось столько, что накрутку ПФ можно встретить на каждом третьем сайте. Часто это делается по заказу конкурентов, часто в качестве эксперимента, часто с целью убрать из ТОП некоторые сайты по определенным запросам, часто для накрутки показателей метрики и т.д. Поле для деятельности очень большое и в этом замешано много исполнителей и заказчиков.
«Качественным трафиком» торгуют во всю (предложения на фриланс-бирже Kwork)
Основные поведенческие факторы на которые оказывается воздействие автоматизированными средствами накрутки ПФ:
Можно ли защититься от накрутки ПФ
Боты маскируются под реального пользователя
Однако, это не значит, что не нужно защищать Метрику! С учетом всех этих подозрительных переходов, количество и качество которых время от времени варьируется в различную сторону, статистика в целом по сайту становится бессмысленной! Разве есть толк анализировать накрученную ботами метрику и для каких целей она может быть полезной?
Ниже мы рассмотрим различные варианты защиты сайта от некачественного трафика с целью воздействия на понижение или повышение поведенческих факторов, в надежде, что в Яндексе уже понимают масштабы внешнего воздействия на их главный инструмент аналитики и там разрабатывают свои механизмы фильтрации такого трафика.
Модификация счетчика Яндекс Метрики
Видоизменив привычный всем код Яндекс Метрики Вы избавляете себя от множества потенциальных проблем сегодня и в будущем. В первую очередь будет полезным спрятать счетчик от людей и роботов, сканирующих контент, от браузеров без поддержки JavaScript и т.д. Делается это просто:
Подключаем Яндекс Метрику в отдельный файл
Код счетчика вставляется в отдельный JS файл. В нашем примере в toolbar.js (ни о чем не говорящее имя), который подключается в шаблоне вашего сайта конструкцией:
Удаляем из счетчика признаки метрики
Модифицированный счетчик
Загрузка в отдельном файле
Если мы загружаем счетчик Яндекс Метрики отдельным файлом (как в примере выше toolbar.js), то код пишется без
Запускаем метрику для живых людей
Загрузку метрики можно сделать умной. Для начала дождаться, чтобы пользователь дождался прогрузки страницы и проскролил ее. Так вы минимизируете нулевые заходы, когда пользователь/бот зашел и сразу же вышел. Данный скрипт загружает счетчик Яндекс Метрики через секунду (цифра 1000 в конце) после скролинга страницы пользователем. Естественно, такая конструкция позитивно влияет и на показатель скорости «Google PageSpeed Insights».
В результате всех вышеописанный манипуляций, код Яндекс Метрики для вставки в toolbar.js выглядит следующим образом:
Все вышеописанные процедуры никаким образом не отразятся на работе Яндекс Метрики: данные по-прежнему в нее будут поступать практически в полном объеме, но без учета определенного мусорного трафика! Также ваш счетчик будет защищен от целого ряда ПО, которые сканируют сайты в поисках номера счетчика, чтобы впоследствии организовать на него прямую атаку!
Примеры блокировок паразитного трафика
После того, как счетчик Яндекс Метрики защищен, но паразитный трафик продолжается, необходимо внимательно изучить тактику накрутчиков ПФ и предпринять меры для блокировки такого трафика. Отдельно необходимо сказать, что универсального решения не существует, так как эмуляция роботности довольно высокая и даже системы фильтрации Яндекса не могут распознавать таких ботов.
Практически во всех атаках можно обнаружить некие общие признаки, по которым и можно блокировать роботов.
Переходы с facebook
Блокировка переходов с facebook в Метрике
Имейте ввиду, такой фильтр стоит включать при агрессивных атаках, так как он будет выключать в аналитике и реальные переходы.
Пример блокировки подсетей IP
Во вкладке «IP-сеть» Вебвизора можна найти подсети атакующих. Очень часто это мобильные операторы:
Передав в Яндекс Метрику IP посетителей (как в примере) мы обнаружим, что IP атакующих разные, но принадлежащие одному оператору и входящие в определенные диапазоны (разнятся в последних числах IP адреса). Блокировать по одному IP не получится, необходимо блокировать диапазон входящих в подсеть IP.
Чтобы в htaccess запретить доступ по IP диапазону, необходимо вычислить CIDR (Classless Inter-Domain Routing, Бесклассовая адресация). Для этого можно воспользоваться любым Whois-сервисом, зная сам IP адрес.
Например, мы видим, множественные атаки с IP адреса 178.176.64.0. Указываем адрес в сервисе https://2ip.ru/whois/, получаем CIDR: 178.176.64.0/19
Вычисление CIDR IP на 2ip.ru
Будьте предельно осторожны при блокировке CIDR диапазонов, используйте их как вынужденную меру, краткосрочное решение и т.д., так как за бортом могут остаться и потенциальные посетители вашего сайта!
Блокировка соцсетей и сайтов по списку
Часто ищет мощный трафик из целого ряда социальных сетей или других сайтов. Как правило, их перечень небольшой, но довольный массивный трафик, который никак не похож на естественный и если у сайта вообще не предполагается такой трафик, то его можно заблокировать перечислением таких сайтов.
Паразитный трафик из социальных и рекомендательных сетей
Список сайтов и социальных сетей, переходы с которых планируется заблокировать, дополняете под свои конкретные нужды.
Показ Яндекс Метрики избранным
Следует иметь ввиду, что счетчик метрики не увидят пользователи пришедшие не из поиска (прямые заходы, закладочный трафик и т.д.) и если у вас преобладает такой трафик, то естественно, такое решение не подойдет для Вашего сайта.
Резюме
Нельзя взять и просто так защитится от массовой накрутки ПФ. В каждом конкретном случае можно избрать свою тактику минимизации вредного воздействия на сайт, которая потребует постоянного наблюдения и корректировки. Внимательно ознакомьтесь с предложенными в статье методами, наверняка они помогут многим.
По состоянию на январь 2021 года ситуация с паразитным трафиком практически вышла из-под контроля Яндекса: бомбардируются уже не только коммерческие тематики и трастовые сайты, но и мало кому известные сайты с трафиком от 50-100 человек в день. Проблема обрела глобальные масштабы!
На все слезные письма по поводу накрутки ПФ Яндекс отвечает, что они постоянно развиваются и в будущем планируют усовершенствовать работу системы фильтрации. Остается ждать! В то время, как текущая система аналитики Яндекса (в зависимости от степени и продолжительности атак на сайт) превращается в бесполезный инструмент!
Специализируюсь на безопасности сайтов: защищаю сайты от атак и взломов, занимаюсь лечением вирусов на сайтах и профилактикой.
Наверняка у Вас есть вопросы, просьбы или пожелания. Не стесняйтесь спросить, я отвечаю всегда быстро.
