Блокировка бот yandex.ru

Я хочу заблокировать все запросы от поискового бота yandex.ru. Это очень интенсивный трафик (2 ГБ / день). Сначала я заблокировал один диапазон IP-адресов класса C, но кажется, что этот бот появляется из разных диапазонов IP-адресов.

Например:

spider31.yandex.ru -> 77.88.26.27 spider79.yandex.ru -> 95.108.155.251 и т. д.

Я могу положить некоторые отрицания в robots.txt, но не уверен, что он уважает это. Я думаю о блокировке списка диапазонов IP-адресов.

Может кто-нибудь предложить какое-то общее решение.

6 ответов

Решение

Мое текущее решение таково (для веб-сервера NGINX):

if ($http_user_agent ~* (Yandex) ) {
        return 444;
}

Это без учета регистра. Возвращает ответ 444.

Эта директива просматривает строку User Agent и, если обнаружен "Яндекс", соединение закрывается без отправки каких-либо заголовков. 444 - это специальный код ошибки, понятный демону Nginx

Не верьте тому, что читаете на форумах по этому поводу! Доверяйте тому, что говорят вам логи вашего сервера. Если бы Яндекс повиновался robots.txt, вы бы увидели доказательства в своих журналах. Я видел, что роботы Яндекса даже не читают файл robots.txt!

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

Введите следующие строки в.htaccess (в корневой папке каждого из ваших сайтов):

SetEnvIfNoCase User-Agent "^Yandex*" bad_bot
Order Deny,Allow
Deny from env=bad_bot

Я так и сделал, и теперь все, что получает Яндекс - это 403 ошибки "Отказано в доступе".

До свидания, Яндекс!

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

Ссылка на форум от Dan Andreatta, и эта другая, содержит некоторые, но не все, что вам нужно. Вы захотите использовать их метод поиска IP-номеров и написать сценарий, чтобы ваши списки были свежими. Затем вы хотите что-то вроде этого, чтобы показать вам некоторые известные значения, включая схемы именования поддоменов, которые они использовали. Следите за их диапазоном IP-адресов, возможно, автоматизируйте что-то, чтобы оценить разумный CIDR (я не нашел упоминаний об их фактическом распределении; может быть, просто Google fail @ me).

Найдите их диапазон IP-адресов как можно точнее, так что вам не придется тратить время на обратный поиск DNS, пока пользователи ждут ( http://yourdomain/notpornipromise), и вместо этого вы только делаете Сравнение совпадений или что-то. Google только что показал мне grepcidr, который выглядит очень актуально. На связанной странице: "grepcidr может использоваться для фильтрации списка IP-адресов по одной или нескольким спецификациям бесклассовой междоменной маршрутизации (CIDR) или произвольным сетям, указанным диапазоном адресов". Я думаю, это хорошо, что это специально созданный код с известным вводом / выводом, но вы знаете, что вы можете воспроизвести функцию миллиардом различных способов.

Самое "общее решение", которое я могу придумать для этого и на самом деле хочу поделиться (говоря о существовании и все такое), - это чтобы вы начали писать базу данных о таких правонарушителях в вашем месте (ах) и потратить немного на - часы, размышляющие и исследующие способы защиты и контратаки поведения. Это поможет вам глубже детектировать вторжение, анализ паттернов и сети, чем это действительно необходимо. Однако в рамках этого исследования есть бесчисленные ответы на этот вопрос, который вы задали.

Я нашел это из-за интересного поведения Яндекса на одном из моих сайтов. Я бы не назвал то, что вижу в своем журнале, оскорбительным, но spider50.yandex.ru израсходовал 2% моего количества посещений и 1% моей пропускной способности... Я могу видеть, где бот действительно злоупотребляет большими файлами и форумы и тому подобное, ни один из которых не доступен для злоупотреблений на сервере, который я смотрю сегодня. Достаточно интересным, чтобы оправдать расследование, был бот, который просматривал /robots.txt, затем ждал от 4 до 9 часов и просил / каталог / не находится в нем, затем ждал от 4 до 9 часов, просил /another_directory/, а затем, возможно, еще немного, и /robots.txt еще раз, повторите ad finitum. Что касается частоты, я полагаю, что они достаточно хорошо себя ведут, и машина spider50.yandex.ru, похоже, уважает /robots.txt.

Я не планирую блокировать их сегодня с этого сервера, но я бы сделал это, если бы поделился опытом Росса.

Для справки о крошечных числах, с которыми мы имеем дело в случае моего сервера сегодня:

Top 10 of 1315 Total Sites By KBytes
 # Hits  Files  KBytes   Visits  Hostname
 1 247 1.20% 247 1.26% 1990 1.64% 4 0.19% ip98-169-142-12.dc.dc.cox.net
 2 141 0.69% 140 0.72% 1873 1.54% 1 0.05% 178.160.129.173
 3 142 0.69% 140 0.72% 1352 1.11% 1 0.05% 162.136.192.1
 4 85 0.41% 59 0.30% 1145 0.94% 46 2.19% spider50.yandex.ru
 5 231 1.12% 192 0.98% 1105 0.91% 4 0.19% cpe-69-135-214-191.woh.res.rr.com
 6 16 0.08% 16 0.08% 1066 0.88% 11 0.52% rate-limited-proxy-72-14-199-198.google.com
 7 63 0.31% 50 0.26% 1017 0.84% 25 1.19% b3090791.crawl.yahoo.net
 8 144 0.70% 143 0.73% 941  0.77% 1 0.05% user10.hcc-care.com
 9 70 0.34% 70 0.36% 938  0.77% 1 0.05% cpe-075-177-135-148.nc.res.rr.com
10 205 1.00% 203 1.04% 920  0.76% 3 0.14% 92.red-83-54-7.dynamicip.rima-tde.net

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

Росс, если ты действительно сердишься на 2ГБ / день, которые ты теряешь для Яндекса, ты можешь их отбить. Вот для чего это! Перенаправьте их из того, что вы не хотите, чтобы они загружались, либо по HTTP 301 непосредственно в поддомен spampoison, либо сверните свой собственный, чтобы вы могли контролировать логику и получать от нее больше удовольствия. Такое решение дает вам инструмент для повторного использования позже, когда это еще более необходимо.

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

217.41.13.233 - - [31/Mar/2010:23:33:52 -0500] "GET /user/ HTTP/1.1" 404 15088 "http://www.google.com/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; MRA 5.1 (build 02228); .NET CLR 1.1.4322; InfoPath.2; .NET CLR 2.0.50727)"
217.41.13.233 - - [31/Mar/2010:23:33:54 -0500] "GET /user/ HTTP/1.1" 404 15088 "http://www.google.com/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; MRA 5.1 (build 02228); .NET CLR 1.1.4322; InfoPath.2; .NET CLR 2.0.50727)"
217.41.13.233 - - [31/Mar/2010:23:33:58 -0500] "GET /user/ HTTP/1.1" 404 15088 "http://www.google.com/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; MRA 5.1 (build 02228); .NET CLR 1.1.4322; InfoPath.2; .NET CLR 2.0.50727)"
217.41.13.233 - - [31/Mar/2010:23:34:00 -0500] "GET /user/ HTTP/1.1" 404 15088 "http://www.google.com/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; MRA 5.1 (build 02228); .NET CLR 1.1.4322; InfoPath.2; .NET CLR 2.0.50727)"
217.41.13.233 - - [31/Mar/2010:23:34:01 -0500] "GET /user/ HTTP/1.1" 404 15088 "http://www.google.com/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; MRA 5.1 (build 02228); .NET CLR 1.1.4322; InfoPath.2; .NET CLR 2.0.50727)"
217.41.13.233 - - [31/Mar/2010:23:34:03 -0500] "GET /user/ HTTP/1.1" 404 15088 "http://www.google.com/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; MRA 5.1 (build 02228); .NET CLR 1.1.4322; InfoPath.2; .NET CLR 2.0.50727)"
217.41.13.233 - - [31/Mar/2010:23:34:04 -0500] "GET /user/ HTTP/1.1" 404 15088 "http://www.google.com/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; MRA 5.1 (build 02228); .NET CLR 1.1.4322; InfoPath.2; .NET CLR 2.0.50727)"
217.41.13.233 - - [31/Mar/2010:23:34:05 -0500] "GET /user/ HTTP/1.1" 404 15088 "http://www.google.com/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; MRA 5.1 (build 02228); .NET CLR 1.1.4322; InfoPath.2; .NET CLR 2.0.50727)"
217.41.13.233 - - [31/Mar/2010:23:34:06 -0500] "GET /user/ HTTP/1.1" 404 15088 "http://www.google.com/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; MRA 5.1 (build 02228); .NET CLR 1.1.4322; InfoPath.2; .NET CLR 2.0.50727)"
217.41.13.233 - - [31/Mar/2010:23:34:09 -0500] "GET /user/ HTTP/1.1" 404 15088 "http://www.google.com/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; MRA 5.1 (build 02228); .NET CLR 1.1.4322; InfoPath.2; .NET CLR 2.0.50727)"
217.41.13.233 - - [31/Mar/2010:23:34:14 -0500] "GET /user/ HTTP/1.1" 404 15088 "http://www.google.com/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; MRA 5.1 (build 02228); .NET CLR 1.1.4322; InfoPath.2; .NET CLR 2.0.50727)"
217.41.13.233 - - [31/Mar/2010:23:34:16 -0500] "GET /user/ HTTP/1.1" 404 15088 "http://www.google.com/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; MRA 5.1 (build 02228); .NET CLR 1.1.4322; InfoPath.2; .NET CLR 2.0.50727)"
217.41.13.233 - - [31/Mar/2010:23:34:17 -0500] "GET /user/ HTTP/1.1" 404 15088 "http://www.google.com/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; MRA 5.1 (build 02228); .NET CLR 1.1.4322; InfoPath.2; .NET CLR 2.0.50727)"
217.41.13.233 - - [31/Mar/2010:23:34:18 -0500] "GET /user/ HTTP/1.1" 404 15088 "http://www.google.com/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; MRA 5.1 (build 02228); .NET CLR 1.1.4322; InfoPath.2; .NET CLR 2.0.50727)"
217.41.13.233 - - [31/Mar/2010:23:34:21 -0500] "GET /user/ HTTP/1.1" 404 15088 "http://www.google.com/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; MRA 5.1 (build 02228); .NET CLR 1.1.4322; InfoPath.2; .NET CLR 2.0.50727)"
217.41.13.233 - - [31/Mar/2010:23:34:23 -0500] "GET /user/ HTTP/1.1" 404 15088 "http://www.google.com/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; MRA 5.1 (build 02228); .NET CLR 1.1.4322; InfoPath.2; .NET CLR 2.0.50727)"
217.41.13.233 - - [31/Mar/2010:23:34:24 -0500] "GET /user/ HTTP/1.1" 404 15088 "http://www.google.com/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; MRA 5.1 (build 02228); .NET CLR 1.1.4322; InfoPath.2; .NET CLR 2.0.50727)"
217.41.13.233 - - [31/Mar/2010:23:34:26 -0500] "GET /user/ HTTP/1.1" 404 15088 "http://www.google.com/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; MRA 5.1 (build 02228); .NET CLR 1.1.4322; InfoPath.2; .NET CLR 2.0.50727)"
217.41.13.233 - - [31/Mar/2010:23:34:27 -0500] "GET /user/ HTTP/1.1" 404 15088 "http://www.google.com/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; MRA 5.1 (build 02228); .NET CLR 1.1.4322; InfoPath.2; .NET CLR 2.0.50727)"
217.41.13.233 - - [31/Mar/2010:23:34:28 -0500] "GET /user/ HTTP/1.1" 404 15088 "http://www.google.com/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; MRA 5.1 (build 02228); .NET CLR 1.1.4322; InfoPath.2; .NET CLR 2.0.50727)"

Подсказка: на сервере нет ни каталога /user/, ни гиперссылки на него.

По данным этого форума, яндекс-бот хорошо себя ведет и уважает robots.txt,

В частности они говорят

Поведение Яндекса во многом похоже на поведение Google в отношении robots.txt . Бот не смотрит на robots.txt каждый раз, когда входит в домен.

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

Лично у меня нет проблем с этим, и googlebot, безусловно, самый агрессивный сканер для сайтов, которые у меня есть.

Раздражайтесь, добавив эти строки в свой файл.htaccess, чтобы охватить всех посетителей 77.88.26.27 (или любого другого IP-адреса), которые пытаются получить доступ к странице, заканчивающейся на.shtml:

# permanently redirect specific IP request for entire site
Options +FollowSymlinks
RewriteEngine on
RewriteCond %{REMOTE_HOST} 77\.88\.26\.27
RewriteRule \.shtml$ http://www.youtube.com/watch?v=oHg5SJYRHA0 [R=301,L]

Этот яндекс-бот теперь прокручивается каждый раз, когда он пытается проиндексировать ваш сайт. Задача решена.

Пожалуйста, люди ищут модель OSI. Я рекомендую вам блокировать эти сети на уровне маршрутизации. Это третий (4-й транспортный) уровень сетевой модели OSI. Если вы блокируете их на уровне сервера, он находится на 4-м (5,6,7-м) уровне и уже прошел. Также ядро ​​может обрабатывать эти запросы в 100 раз лучше, чем сервер Apache. RewriteRule поверх RewriteRule, директивы SetEnv и т. Д. Просто глючат ваш сервер, независимо от того, представляете ли вы крутой 403. Запрос - это запрос, и Яндекс также Baidu выполняет их много, а Google также сканирует в фоновом режиме! Вам действительно нравится быть затопленным запросами, это стоит вам слотов веб-сервера, и Baidu известен тем, что делает это намеренно.

61.51.16.0 - 61.51.31.255 61.51.16.0/20 # (Baidu China - Beijing)
14.136.0.0 - 14.136.255.255 14.136.0.0/16 # (Baidu China - HK)
123.125.71.0 - 123.125.71.255 123.125.71.0 # (Baidu China)
14.208.0.0 - 14.223.255.255 14.208.0.0/12 # (Baidu China)
95.108.241.0 - 95.108.241.255 95.108.241.0 # (ЯндексБот Россия)
95.108.151.0 - 95.108.151.255 95.108.151.0 # (ЯндексБот Россия)
119.63.192.0 - 119.63.199.255 119.63.192.0/21 # (Baidu Japan Inc.)
119.63.192.0 - 119.63.199.255 119.63.196.0/24 # (Baidu Japan Inc.)        
180.76.0.0 - 180.76.255.255 180.76.0.0/16 # (Baidu China, Baidu Plaza, Пекин)
220.181.0.0 - 220.181.255.255     220.181.108.0/24  # (CHINANET Beijing Province Network)

Новые диапазоны: (Обновлено, 8 мая 2012 г.)

123.125.71.0 - 123.125.71.255 123.125.71.0/24 # (Baidu China)
202.46.32.0 - 202.46.63.255 202.46.32.0/19 # (Baidu China)

Новые диапазоны: (Обновлено Солнце, 13 мая 2012 г.)

39.112.0.0 - 39.127.255.255 39.112.0.0/12 # KOREAN
211.148.192.0 - 211.148.223.255 211.148.192.0/19 # Китай (Шэньчжэнь)
Другие вопросы по тегам