Я хочу заблокировать все запросы от поискового бота yandex.ru. Это очень интенсивный трафик (2 ГБ / день). Сначала я заблокировал один диапазон IP-адресов класса C, но похоже, что этот бот появляется из разных диапазонов IP.
Например:
spider31.yandex.ru -> 77.88.26.27 spider79.yandex.ru -> 95.108.155.251 и т. д.
Я могу отрицать это в robots.txt, но не уверен, уважает ли он это. Подумываю заблокировать список диапазонов IP.
Может кто-нибудь предложить какое-то общее решение.
Не верьте тому, что вы читаете об этом на форумах! Доверяйте тому, что вам говорят журналы вашего сервера. Если бы Яндекс подчинялся robots.txt, вы бы увидели доказательства в своих логах. Я сам убедился, что роботы Яндекса даже не ЧИТАЮТ файл robots.txt!
Не тратьте время на длинные списки IP-адресов, которые только сильно замедляют работу вашего сайта.
Введите следующие строки в .htaccess (в корневой папке каждого из ваших сайтов):
SetEnvIfNoCase User-Agent "^Yandex*" bad_bot
Order Deny,Allow
Deny from env=bad_bot
Я это сделал, и все, что теперь получает Яндекс, - это ошибки 403 Access denied.
Прощай, Яндекс!
Я слишком молод (репутация), чтобы размещать все URL-адреса, которые мне нужны, в виде гиперссылок, так что извините за мои URL-адреса в скобках, пожалуйста.
В ссылка на форум от Дэна Андреатты, и этот другой, есть некоторые, но не все, что вам нужно. Вы захотите использовать их метод поиска 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 часов и запрашивал / directory / не в нем, затем ждал от 4 до 9 часов, запрашивая / another_directory /, затем, возможно, еще несколько, и снова /robots.txt, повторять до конца. Что касается частоты, я полагаю, они достаточно хорошо себя ведут, и машина 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 непосредственно в поддомен спамотравы, либо сверните свой собственный, чтобы вы могли контролировать логику и получать больше удовольствия от нее. Такое решение дает вам инструмент для повторного использования позже, когда это станет еще более необходимым.
Затем начните искать в своих журналах такие забавные забавные истории:
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, безусловно, является самым агрессивным поисковым роботом для сайтов, которые у меня есть.
Мое текущее решение (для веб-сервера NGINX):
if ($http_user_agent ~* (Yandex) ) {
return 444;
}
Это нечувствительно к регистру. Он возвращает ответ 444.
Эта директива просматривает строку User Agent и при обнаружении «Яндекс» соединение закрывается без отправки заголовков. 444 - это настраиваемый код ошибки, который понимает демон Nginx.
Не бойтесь добавить эти строки в файл .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 over RewriteRule, директивы SetEnv и т. Д. Просто беспокоят ваш сервер, независимо от того, показываете ли вы крутой 403. A Request - это запрос, и Яндекс также 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 - H.K.) 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 # (YandexBot Russian Federation) 95.108.151.0 - 95.108.151.255 95.108.151.0 # (YandexBot Russian Federation) 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, Beijing) 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 # China (ShenZhen)