Вы здесь

Как бороться с Интернет-роботами. Часть 1

Robot and WomanВ самом начале, человек, который помог мне с сайтом, на вопрос о методах защиты от спама и взлома ответил, что это дело хостера (мы же деньги платим), в крайнем случае, есть капча и блокировка по IP. А если взломают – восстановить из копии. Есть такая точка зрения... Да вот, практика показывает, что любая проблема, пущенная на самотёк, превращается в стихию.
 
Дело в том, что по мере жизни, число посетителей сайта должно расти. А если сайт появится (хоть по одной позиции) в первой 20-ке поисковика – жди прилива. Да, пена сойдёт, но грязь останется.
 
«Незваный гость – хуже татарина».
 
 
Все опубликованные части по этой теме:

  1. Как бороться с Интернет-роботами. Часть 1
  2. Моя борьба с Интернет-роботами. Часть 2
  3. Борьба со спамом и Интернет-ботами. Часть 3
 
Наверняка у кого-то есть готовые рецепты. Что-то можно найти в Интернете, о чём-то догадаться самому. Хотя, по мне, эта тема неисчерпаема, как борьба добра со злом. И я её буду «раскручивать» со стороны новичка, а не профессионального истребителя спамеров и хакеров. Из этого можно сделать цикл заметок или что-то другое. А что конкретно – зависит от вас, уважаемый читатель!
 
Сначала попробуем как-то классифицировать посетителей. Прежде всего – это люди, любимые наши читатели и возможные пользователи наших продуктов. Их мы должны холить и лелеять. Дальше идут роботы: роботы поисковых систем («Яндекс», «Гугл» и пр.), SEO-роботы (измеряющие показатели сайта) и роботы-«вредители», которые занимаются спамом, взломом и прочими неблаговидными и малопонятными делами.
 
Наша тема – роботы. Потому о них и речь. Легко видеть, что роботам поисковых систем надо помогать и подсказывать. Я об этом сделал пару заметок: «Регистрация сайта, карта сайта и не только…» и «Немного о сайте: robots.txt». Стоит добавить, что изменения данных в robots.txt «паучки» подхватывают не на лету, а через какие-то промежутки времени. Например, сейчас бот «Яндекса» перечитывает мои настройки где-то раз в пол дня.
 
Второй момент. Разные роботы понимают настройки в robots.txt по-разному. «Яндекс» - как руководство к действию, а «Гугл» - как рекомендацию. Т.о., если вы запретили что-то индексировать, «Yandex» сразу перестанет это делать, а «Google» - поначалу перестанет только показывать (скроет в результатах поиска), а индексировать перестанет позже. И действительно, зачем это делать, если показывать не надо?
 
Третий момент. Некоторые директивы роботы игнорируют. Например, «Гугл» официально пропускает ограничение в «Craw-Delay». Он использует своё, которое можно установить или изменить в панели Веб-мастера. Так же, стоит быть внимательным и не попадаться в логическую ловушку, как я, слишком широко трактуя некоторые настройки. Если написать в robots.txt так:
 
User-agent: Yandex
Host: <мой сайт>
 
User-agent: *
Crawl-delay: 10
# Directories
Disallow: /includes/
Disallow: /misc/
Disallow: /modules/
Disallow: /profiles/
Disallow: /scripts/
Disallow: /themes/
 
То, проверка файла robots.txt в WebMaster-е Яндекса покажет, что он читает только строки: «User-agent: Yandex» и «Host: <мой сайт>», а остальные – нет.
 
Правила в разделе «User-agent: *» касаются только ботов, без своего раздела. Как только мы напишем «User-agent: <имя агента>», указанный робот будет читать правила именно здесь. А при наличии нескольких секций для разных «паучков», и необходимости неких универсальных правил – их придётся повторять для каждого. Вывод: разделы лучше не множить, в идеале обходясь одним для всех - «User-agent: *».
 
Что ещё можно добавить?.. Практика показала, что некоторые роботы мне совсем не нужны. Например, «Байду». Робот этого поисковика столь же основателен, как и «Гугл», но работает на китайскую сторону, где нет моих читателей и пользователей. Так зачем мне (и моему хостеру) лишняя нагрузка? Правильно, его можно попросить больше не приходить. Для этого я сделал секцию исключения:
 
User-agent: Baiduspider
Disallow: /
 
И что, он уже не придёт? Как сказать... Robots.txt – это табличка на магазине, запрещающая проход собакам и людям с мороженым. Как там, в «Тайне третьей планеты»? «Человекцарь природы. — Да, только звери об этом не знают». Все эти надписи и таблички – для порядочных. А если надеть чёрные очки, накинуть глубокий капюшон или глотнуть для «храбрости»… Кстати, даже роботы «Гугла» часто «переодеваются», приходя под видом человека. В Интернете правило одно: «что не запрещено, то разрешено».
 
Что ж, вот мы и начали погружаться в мир ползающих, жующих и летающих. Чтобы не повторяться, даю ссылки, о чём уже писал: о «Манипуляция (подмена)» (решение вопроса с нежелательными сайтами, не имеющих своих роботов), «Brute force (брутфорс)». Помним, что капча и блокировка по IP в админке Drupal-а это последний рубеж, а robots.txt – это всего лишь табличка дома «высокой культуры» и свод правил аристократии в одном флаконе.
 
Жизнь бьёт ключом, «чёрный» список блокированных адресов растет, уходит за 1000… Да, если правильно его вести: дата, имя адреса (например, ISP), причина – можно выработать собственные правила и сроки перепроверки адресов (а вдруг они исправились?), и заметить некую группировку нехороших IP. Это позволит применять запрет по диапазону, и снизить остроту вопроса. Но, список-то всё одно – растёт. Нужны дополнительные инструменты!
 
Эх, если бы у роботов был какой-то свой ID, по которому их можно заблокировать... Есть такая вещь! Она называется «User-Agent». Это некая подпись, идентифицирующая посетителя (программу, через которую работает сам человек или другая программа). Конечно, этой «подписи» может и не быть, она может быть испорчена или подделана. По большому счёту, подписи не уникальны, но могут быть информативны. Где же ознакомится с личными подписями посетителей?
 
А в логах сервера! Мой сайт работает под управлением сервера Apache и данные о посещениях находятся файле «access.log». Где всё время ведётся протокол о том, кто, как, куда и когда приходил. По правилам безопасности (установленные хостером) у меня нет прямой возможности чтения, и я скачиваю его из специального менеджера. Сами записи в «access.log» ведутся последовательно. И в конце каждой строки легко выделяются «Юзер-Агенты»:
 
46.xxx.170.xxx - - [20/Mar/2015:23:42:09 +0200] "GET /ru HTTP/1.0" 200 37953 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2a1pre) Gecko/20090402 Firefox/3.6a1pre (.NET CLR 3.5.30729)"
157.55.39.xxx - - [20/Mar/2015:23:58:22 +0200] "GET / HTTP/1.0" 200 8273 "-" "Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)"
 
Так вот, User-Agent – это "Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2a1pre) Gecko/20090402 Firefox/3.6a1pre (.NET CLR 3.5.30729)"
 
В частности, «bingbot/2.0; +http://www.bing.com/bingbot.htm» - это Microsoft bingbot с указанием родного сайта. Хороший робот.
 
Ясно. Берём логи, грузим их, например в Excel и выделяем записи с уникальными «User-Agent»-ами. Большинство ботов в своём имени содержат частичку «bot» или «spider» и они хорошо видны. Допустим, я заподозрил, что какое-то слово (или группа) может быть меткой или именем бота. Как узнать? Надо обратиться к специализированному сайту, или «пробить» в «Гугле». А если мы захотим по IP-адресу узнать, кто оттуда приходит – можно зайти сюда: http://www.botsvsbrowsers.com/, где в разделе User Agent IP Directory ввести нужный IP. И получим список «User-Agent»-ов.
 
Эти адреса Вам могут пригодиться:
 
Анализатор User-Agent-ов:
 
Сверить имя бота по списку можно здесь
 
Список агентов (роботов и других программ) с пояснениями:
 
Уточнить что это за бот (принцип действия и пр.):
 
 
Чтобы определить стратегию, я классифицировал свой «зоопарк».
Что у меня вышло?
 
  • Стандартные поисковые боты. Работают на поисковые сайты. Имеют имя, адрес, почту, обратную связь, слушаются robots.txt, где есть возможность их отключить.
  • Вменяемые боты: такие же, но работают обычно с SEO-сайтами.
  • Обманщики: всё тоже, но robots.txt не слушают и/или нет возможности их там отключить (т.е., их собственник сознательно вводит нас в обман, сообщая, что данный робот имеет средство отключения и придерживается правил индексации).
  • С претензией на признание: могут иметь имя или особую подпись в «User-Agent», но обратной связи с владельцем (производителем) нет и, скорее всего, правила не соблюдают.
  • Любительские: отличаются ошибками оформления «User-Agent»-а. Цель их создания – любая.
  • Хамелионы: качественно сделанные боты, имитирующие или использующие «User-Agent»-ы стандартных браузеров или поисковых систем. Обычно применяют для рассылки спама, взлома, атак и пр. задач.
 
Собственно, с этого момента я и занялся работой с нежелательными «гостями». Тщательно отсмотрев логи (достаточно взять за последний месяц), «пробив» адреса «чёрного» списка, я получил предмет анализа. После этого, поделил роботов на две группы: вменяемых (имеют свой сайт, обратную связь, читают и прислушиваются к настройкам robots.txt) и «диких», которые ведут себя как вздумается. Стратегия «нарисовалась» автоматически:
 
  1. С кем можно «договориться» – «беседуем» в robots.txt.
  2. С кем нельзя, но у него есть свой «User-Agent»-у – блокировать по «агенту» в .htaccess.
  3. Иначе, определять IP или его группу (диапазон) и уже по ней блокировать в .htaccess.
  4. В тяжёлых случаях – искать иные средства (например, анализирующие особенности поведения).
 
Будьте внимательны, в качестве «User-Agent»-а в robots.txt можно использовать только официальное имя бота (смотрим способ запрета на его родном сайте), а в .htaccess – реальный (или уникальный кусок) «User-Agent»-а, который Вы решили использовать.
 
С роботами поисковых систем всё очень просто: оставляем только те, которые используют наши граждане, и подстраиваемся под их особенности. А что делать с SEO-ботами? Они могут быть полезными... Собирая информацию, они дают «пищу» о примерной стоимости сайта, стоимости «клика», «важности» и «актуальности» размещённой информации… Думаю, что дружить можно только с «культурными читателями», уважающих правила и не передающих информацию без моего согласия.
 
Что ж, продавать свой сайт или зарабатывать на нём деньги я не собираюсь. Сайт не коммерческий. И поэтому, я смело послал всех SEO-ботов в «сад». Туда же пошли разные версии «даунлоад»-, «спам»- и прочих роботов. А если я вдруг поменяю стратегию – подберу себе SEO-«компанию», с которой буду «дружить». Как говорил товарищ Ленин: «Надо сначала разделиться, чтобы потом - объединиться». Как-то так!
 
Очень скоро у меня «нарисовался» список на отключение для «послушных паучков»: AhrefsBot, archive.org_bot, Baiduspider, dotbot, grapeshot, MJ12bot, proximic, sistrix, spbot. Где же их правильнее отключать? Многие говорят, - лучше сразу в .htaccess. Да, это снизит трафик, но несколько повысит нагрузку на сервер (анализ условий доступа). Давайте «.htaccess» оставим для «непокорных», а для «ласковых» у нас есть robots.txt:
 
User-agent: AhrefsBot
Disallow: /
 
User-agent: archive.org_bot
Disallow: /
 
User-agent: Baiduspider
Disallow: /
# Baiduspider-video
# Baiduspider-news
# Baiduspider-image
# Baiduspider-favo
# Baiduspider-cpro
# Baiduspider-ads
 
User-agent: CrazyWebCrawler-Spider
Disallow: /
 
User-agent: dotbot
Disallow: /
 
User-agent: grapeshot
Disallow: /
 
User-agent: MJ12bot
Disallow: /
 
User-agent: proximic
Disallow: /
 
User-agent: sistrix
Disallow: /
 
User-agent: spbot
Disallow: /
 
Вот так, «забанив» часть роботов «по-белому», можно заняться другими. А будут хулиганить – потопим «по-чёрному» (в .htaccess). Стоит напомнить, что боты можно блокировать как по «имени» («User-Agent»), так и по «ссылке» («Referer», откуда пришли) и по IP-адресу. По большому счёту, у робота может и не быть имени, он может шифроваться под «липовым» «User-Agent» или не иметь такового, заходить под разным IP. И много чего ещё делать…
 
Немного «лирики». Стоит чётко помнить, что любой текст кода должен быть продуманным: чётким, конкретным и минимальным. Чем меньше написано, тем легче и быстрее читается (и не только человеком), быстрее отработает сервер, быстрее найдутся ошибки. В Интернете вы найдёте кучу всяких советов, что и как надо сделать. И многие их просто скопируют, не задумываясь о последствиях, не задавая вопрос о надобности. А сто́ит!
 
В частности, я сам чуть не «купился» на одну рекомендацию. В «Паутине» она часто встречается «под разным соусом», но суть которой – в необходимости немедленной защиты файла .htaccess от возможности постороннего чтения людьми или роботами. Я сразу сделал нужные изменения (отлаживал в локальном варианте) по приведённым примерам. Но, потом задумался… А почему?
 
Простой способ проверить защищённость вашего .htaccess – попытаться открыть в инет-эксплорере ссылку своего сайта на .htaccess: «http://<мой сайт>/.htaccess». Если у вас открывается – значит, у вас проблемы. Нет – да вы крутой чел!
 
Дело в том, что в Apache2 (не знаю как раньше), файл .htaccess уже защищён настройками.
В «локальном» «Апаче» это сделано в файле «C:\Apache2\conf\httpd.conf»:
 
# The following lines prevent .htaccess and .htpasswd files from being viewed by Web clients.
<FilesMatch "^\.ht">
    Order allow,deny
    deny from all
    Satisfy All
</FilesMatch>
 
Хостер не даёт мне ковыряться в своём Апаче, потому я просто глянул версию и сделал контрольную проверку. Ну, а если защиты нет, то тогда её надо поставить в .htaccess (одним из 2-ух способов):
 
1 способ – как написано выше в httpd.conf, или сделать тоже, но в .htaccess
2 способ – в .htaccess:
<files .htaccess>
 Order allow,deny
 deny from all
</files>
 
 
Переменка кончилась, займёмся «непокорными» и «дикими». В «Гугле» много примеров, как в «.htaccess» заблокировать бота по «агенту» с помощью директивы «SetEnvIf». Только в этих примерах не пишется, что для её использования необходимы загруженные моды «mod_authz_host» и «mod_setenvif». А ведь, если их не будет (а кто знает, что там задумал хостер?..) – такая блокировка не сработает. В следующем примере показываю, как я блокирую боты с пустыми и фальшивыми агентами:
 
###
# BLOCK BAD BOTS by User-Agent
###
 
# Для правильно работы требуются моды "mod_authz_host" и "mod_setenvif"
<IfModule mod_authz_host.c>
 <IfModule mod_setenvif.c>
 
# Пометка бота с пустым User-Agent:
# создаём переменную-маркер окружения «GoAway» со значением «1»
    SetEnvIf User-agent ^$ GoAway=1
# Пометка бота с "фальшивым" User-Agent "-"
    SetEnvIf User-agent ^-$ GoAway=1
# Можно продолжать добавлять строки с другими плохими User-Agent-ами, например:
    SetEnvIf User-Agent linkdexbot.* GoAway=1
    SetEnvIf User-Agent netEstate\sNE\sCrawler GoAway=1
# и т.д.
    <Limit GET POST HEAD >
      Order allow,deny
      allow from all
      deny from env=GoAway
    </Limit>
 
 </IfModule>
</IfModule>
 
Мои пояснения:
«^» и «$» - символы начала и конца строки (слова или группы слов).
«.» – (если не «экранировано» обратной косой-слэшем) обозначает любой символ.
«*» - ставится после символа или группы символов (группа пишется в круглых скобках) и обозначает, что они могут повторяться любое количество раз. Т.о., «.*» - означает любой набор символов.
Выражение «netEstate\sNE\sCrawler» расшифровывается как «netEstate NE Crawler» (с пробелами между словами). Я вынужден использовать вместо пробела его заменитель - «\s», иначе система поймёт это выражение как три разные переменные. Кстати, пробел можно заменять по-разному. О способах можно почитать здесь.
 
Метку (переменную окружения), которую я назвал «GoAway», можно назвать и по-другому, например, «bad_bot». Присвоение ей значения (в данном случае) не обязательно, но желательно. И это не обязательно цифра.
 
Так же, боты можно отключать, используя директиву SetInvIfNoCase (появилась в Apache 1.3), которая действует так же, как и SetEnvIf, но при сравнении переменных не учитывает регистр букв. Или с помощью модуля «mod_rewrite» (см. RewriteCond, RewriteRule). Но, я выбрал свой способ.
 
Хорошо, идём дальше… Про «агенты» мы поговорили, теперь о блокировке по IP. Есть масса адресов, с которых к нам «приползают» боты с фальшивыми агентами. Что делать? Если бот имеет фиксированный адрес или их диапазон, лучший путь – блокировка по IP. Любая группа адресов, злоупотребляющая активностью – потенциальный кандидат на блокировку. Помните, я писал, что делаю группировки адресов в своём чёрном списке? Это мне пригодилось.
 
Выяснилось, что больше всего меня достают боты «Amazon» (Amazonaw.com, Amazon.com, Amazon Technologies, Merck and Co., E.I. du Pont de Nemours and Co. и т.д.) и «Digital Ocean». В основном, «Digital Ocean» использует «вменяемые» боты. Например, «spbot». Его «User-Agent»: «Mozilla/5.0 (compatible; spbot/4.0.7; +http://OpenLinkProfiler.org/bot )»; он имеет страничку: «http://OpenLinkProfiler.org/bot»; и фиксированный список адресов:
    104.132.*.*
    107.170.*.*
    162.243.*.*
    192.241.*.*
    192.81.*.*
    198.199.*.*
    198.211.*.*
    208.68.*.*
 
Отключается просто:
User-agent: spbot
Disallow: /
 
Аналогичная ситуация с другими ботами «Digital Ocean» - большинство из них управляемые, легко «вычисляются» и блокируются в robots.txt. А вот, с «Amazon» - сложнее. В «Амазонке», кроме хорошо известного и управляемого «паучка» «proximic», мало чего хорошего… И творится чёрт-те что. Прикинув, что к чему – решил с ним прощаться и блокировать по IP. И не по одному, а диапазоном.
 
Блокировать «Амазон»-ботов лучше в .htaccess, разгрузив тем самым Drupal и ускорив работу сайта (робот будет «вышибаться» прямо с порога). Плюс, это сократит «чёрный» список в «админке»: меньше записей – больше порядка. Как в .htaccess можно блокировать диапазон адресов? Для этого применяется директива «Deny from». Способы указания:
 
1 способ:
deny from 192.168.*.*
* - любой номер, т.о. получим 192.168.0.0 - 192.168.255.255
 
2 способ:
deny from 192.168.
=> тоже получим 192.168.0.0 - 192.168.255.255
 
3 способ – это использование классовой или бесклассовой адресации (CIDR)
 
Мне приятнее и удобнее применять бесклассовую адресацию. Выглядит красиво:
deny from 23.20.0.0/14
«/14» – это «+0.3.255.255», что даст диапазон 23.20.0.0 - 23.23.255.255
 
Если мы будем использовать бесклассовую адресацию, где же взять CIDR конкретного «вредителя»? Его можно посчитать самому или подсмотреть на специализированном сайте, например на myip.ms. Тут мы введём интересующий адрес, а он нам даст по нему развёрнутую информацию и CIDR в придачу. Вот так!
 
В итоге, в .htaccess я написал следующее:
###
# USER IP BANNING
###
 
<IfModule mod_authz_host.c>
 
 <Limit GET POST HEAD >
    Order allow,deny
    allow from all
 
# Блокируем диапазоны Amazon
# CIDR: 23.20.0.0/14    NetRange: 23.20.0.0 - 23.23.255.255
# CIDR: 50.16.0.0/14    NetRange: 50.16.0.0 - 50.19.255.255
# CIDR: 52.0.0.0/11     NetRange: 52.0.0.0 - 52.31.255.255
# CIDR: 52.32.0.0/11    NetRange: 52.32.0.0 - 52.63.255.255
# CIDR: 52.64.0.0/11    NetRange: 52.64.0.0 - 52.95.255.255
# CIDR: 54.72.0.0/13, 54.80.0.0/12
#     NetRange: 54.72.0.0 - 54.95.255.255
# CIDR: 54.144.0.0/12   NetRange: 54.144.0.0 - 54.159.255.255
# CIDR: 54.160.0.0/12   NetRange: 54.160.0.0 - 54.175.255.255
# CIDR: 54.176.0.0/12   NetRange: 54.176.0.0 - 54.191.255.255
# CIDR: 54.192.0.0/12   NetRange: 54.192.0.0 - 54.207.255.255
# CIDR: 54.208.0.0/13, 54.216.0.0/14, 54.220.0.0/15
#     NetRange: 54.208.0.0 - 54.221.255.255
# CIDR: 54.224.0.0/12   NetRange: 54.224.0.0 - 54.239.255.255
# CIDR: 54.240.0.0/12   NetRange: 54.240.0.0 - 54.255.255.255
# CIDR: 79.125.0.0/18   NetRange: 79.125.0.0 - 79.125.63.255
# CIDR: 107.20.0.0/14   NetRange: 107.20.0.0 - 107.23.255.255
# CIDR: 174.129.0.0/16 NetRange: 174.129.0.0 - 174.129.255.255
# CIDR: 184.72.0.0/15   NetRange: 184.72.0.0 - 184.73.255.255
# CIDR: 184.169.128.0/17   NetRange: 184.169.128.0 - 184.169.255.255
 
    deny from 23.20.0.0/14
    deny from 50.16.0.0/14
    deny from 52.0.0.0/11
    deny from 52.32.0.0/11
    deny from 52.64.0.0/11
    deny from 54.72.0.0/13
    deny from 54.80.0.0/12
    deny from 54.144.0.0/12
    deny from 54.160.0.0/12
    deny from 54.176.0.0/12
    deny from 54.192.0.0/12
    deny from 54.208.0.0/13
    deny from 54.216.0.0/14
    deny from 54.220.0.0/15
    deny from 54.224.0.0/12
    deny from 54.240.0.0/12
    deny from 79.125.0.0/18
    deny from 107.20.0.0/14
    deny from 174.129.0.0/16
    deny from 184.72.0.0/15
    deny from 184.169.128.0/17
 
 </Limit>
</IfModule>
 
 
Вы ещё не устали читать? А я уже устал набивать текст. Сожалею, подвожу черту и прерываюсь на ужин. Как вы заметили, в основном мы обсуждали поисковые роботы. А есть ещё спам-роботы, роботы-взломщики и пр. Кто сказал, что всё вышесказанное к ним не применимо? Применимо. Хотя, чаще их приходится ловить другими способами. Можно вспомнить о блокировках по регионам, разные трюки на основе анализа поведения и прочие «комбайны».
 
Мы всего лишь в начале пути!
 
 
13.04.2015 г.    Карандаш.

 

 
P.S.: (24.02.2016)
            Для компании Amazon Inc. я привёл не все существующие диапазоны адресов, а лишь те, с которых ко мне заходили её роботы. Если кого будет интересовать, как узнать все диапазоны адресов какой-либо компании, страны, региона – это будет в третьей части статьи. Не прощаюсь!
 

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer