Защита веб-сайта от автоматического скачивания программами. Защищаемся средствами Unix [ban_mega_dl.sh v.3.0]

Зачем массово качаются сайты? Сходу можно указать две причины. Кому-то Ваш сайт очень понравился и этот “кто-то” нашел на нем много полезной для себя информации. Вот и хочется человеку сделать себе локальное “зеркало” этого сайта, для того, чтобы не выходя в Интернет как следует изучить информацию на нем.

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

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

Нет. Гордость отодвинем на второе место. Ведь мы же не станем гордиться, если у нас угонят машину, думая, какая же классная была она у нас, раз ее решили угнать. Будем пытаться защищаться.

Но, от воровства контента 100% средств защиты нет И это аксиома! Хотя… Вообще, такая защита есть - Вам попросту не стоит выкладывать в Сеть то, чего опасаетесь, что у Вас украдут… Если бы все владельцы сайтов боялись кражи контента, в сети Интернет информационных веб-ресурсов не существовало бы в принципе.

Идею написать материал по этой теме, а также реализовать защиту для live.daemony.org от тотального скачивания мне “подбросил” один из посетителей из сетей Укртелекома, который вчера вечером с IP адреса 92.113.86.1X3 пытался выкачать страницы этого блога программой HTTrack (судя по User-Agent). Адрес я забанил в .htaccess, но IP Укртелеком выдает динамические и такая защита - всего временная “затычка”. Я отправился гуглить на тему соответствующего решения появившейся проблемы.

Честно говоря, нагуглил не очень много. Готовых, действительно стоящих решений я не нашел. То ли народ проблемой выкачивания сайтов вовсе не озабочен, то ли я плохо искал. Примеры, которые я нашел, мне показались малоэффективными, а некоторые вроде “банить по User-Agent” - извините, меня глупыми. Ведь не секрет какие программы используются для скачивания сайтов. Типичные примеры - TeleportPro, Offline Explorer, ДискоКачалка, да и тот же HTTrack. Все эти программы в своих настроках позволяют переиначить агента, а многие уже по-умолчанию используют что-то типа “Internet Explorer 6.0“. Потому, решил ковырять тему самостоятельно. А вдруг что-то и получится.

Еще из списка предлагаемых на форумах способов запрета скачивания сайтов можно назвать установку ограничений на количество запросов к сайту в единицу времени. В принципе, решение имеет право на жизнь. Да, кстати, и у “Гугль-Карты” такая защита очень хорошо работает. При очень большом количестве запросов в какой-то момент времени на сайте появляется приглашение подтвердить, что страницы запрашивает не программа-робот, а живой человек (нужно ввести капчу). Программы, для скачивания карт “идут лесом” или по крайней мере работают не так эффективно, как планировалось. Реализация этого способа для меня показалась несколько затруднительной. С моими скудными знаниями PHP такое врядли получится сделать в короткие сроки.

Остановился я на идее, которая по своей сути задействует тест Тьюринга - самый надежный на сегодняшний день способ отличать зашедшего на сайт человека от программы-робота. Суть в нашем случае состоит в том, чтобы в коде страниц сайта оставить злостному качальщику ссылку-ловушку. Ссылку, которая будет существовать, но не будет видна для человека, просматривающего страницу, либо будет для него неинформативной. Человек по такой ссылке никогда целенаправленно не нажмет, а вот программа, создающая “зеркало” на локальном жестком диске, пройдет по всем (как минимум, внутренним) ссылкам сайта, которые отыщутся в коде первой попавшейся (обычно домашней) страницы.

Разобрав концовку лога сервера Apache на предмет посещения ссылки-ловушки, нам ничего не будет стоить забанить IP такого “посетителя” на определенное время или навсегда.

Я хочу поделиться своим примером защиты от скачивания, который реализовал сегодня на этом сайте. Не исключено, что чем-то он может показаться Вам “кривым”, в чем-то неоптимальным (я имею в виду сами скрипты). Что-ж, я буду рад выслушать в комментариях Ваши дополнения и предложения. А вот если мой пример принесет Вам практическую пользу, я за Вас порадуюсь. У меня пока что система работает в режиме тестирования.

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

1. Программа - робот, а не человек, поэтому, при потоковом скачивании сайта она проходит по всем ссылкам на страницах, которые находит в HTML коде, в отличии от человека разумного . Программа может не проходить по JavaScript ссылкам - и в 99% случаев так и есть (в качалках обычно JavaScripts не поддерживается), но нам это не нужно.
2. Следует учесть, что программа может быть настроена таким образом, чтобы не проходить по заданным пользователем URL’ам.
3. Пользователи качалок могут настроить программу не переходить и не качать страницы по внешним ссылкам, но в подавляющем большинстве случаев они будут настраивать программу для скачивания файлов по ВСЕМ ВНУТРЕННИМ ссылкам. Ведь они собираются скачать Ваш сайт.
4. Пользователь, запустивший качалку, может иметь динамический IP адрес, а следовательно, забанив его мы в будущем можем “наказать” ни в чем не повинную третью сторону. Поэтому бан следует устанавливать временно, но все же хранить старые логи, с целью выявления “рецидивистов” и применения соответствующего (более жестокого) наказания.

Последовательность реализации

1. Согласно характеристике враждебного посетителя, программа-качалка при попытке загрузить сайт, пройдет по ссылкам сайта, которые найдет в HTML коде первой попавшейся страницы и так далее, до той глубины вложенности, которую задал ей пользователь. Задействуем URL ловушку на каждой странице сайта, скрыв ее от обычного пользователя. Программе такой URL будет доступен. URL будет установлен в header шаблона сайта, поскольку он вызывается при генерации каждой страницы. Также вполне стоит вставить URL ловушку в других частях шаблона: боковой колонке, подошве и т.п.
2. Анализируя по cron‘у последние N строк файла access.log сервера Apache, выберем IP адреса тех, кто прошел по URL ловушке и поместим эти IP в специальный лог-файл, а следом и в .htaccess с директивой “Deny from“.
3. При реализации пункта 1 следует учесть случай, когда наш сайт приходит качать продвинутый юзер, знающий, что на нашем сайте стоит защита от скачивания и знающий по какому URL проходить нельзя, дабы не попасть в бан лист. Такой юзер заранее может настроить программу не проходить по такому URL, следовательно, защитный URL следует сделать ДИНАМИЧЕСКИ изменяющимся.
4. При реализации всей схемы нельзя забывать про поисковых роботов Google, Yandex и т.п. Ведь их банить нельзя, а действовать они будут так же как и программа-качалка. Поэтому, следует продумать механизм отличения роботов поисковых систем, от программ качалок.

Задача поддается реализации с использованием стандартных средств ОС FreeBSD, либо другой Unix-like системы.

Всего мне пришлось написать два скрипта. Первый скрипт я буду запускать по cron раз в пять минут. Он будет проверять последние, допустим, 5000 строк файла access.log на предмет “интересной” ссылки и, в случае ее нахождения, реагировать соответствующе. Второй скрипт будет вызываться раз в час (например, на 20-й минуте часа) и, в случае если за последний час был кто-то пойман, архивировать имеющиеся данные, очищать текущий список заблокированных хостов и отправлять администратору уведомление со списком забаненных.

Для хранения скриптов и прочих файлов я создам отдельный каталог. Основная директория сайта у меня в папке /www/live.daemony.org Здесь у меня расположены каталоги logs/ (с логами сервера), htdocs/ (с непосредственно самими файлами сайта) а теперь еще добавится каталог, допустим, shell, в котором все и будет происходить.

$ ls -la /www/live.daemony.org/
...
drwxrwx---   6 daemony   www  1536 17 апр 13:45 htdocs
drwxr-x---   3 daemony   www   512 17 апр 11:04 leech
drwxr-x---   2 daemony   www  2048 17 апр 13:35 logs
drwx--x---   2 daemony   www   512 17 апр 17:35 shell
...

Обратите внимание на права доступа. Я сделал каталог shell доступным для пользователя www, потому что в нем будет храниться файл с URL-ловушкой, который будет инклюдиться в PHP шаблон сайта. Создадим, собственно, сам файл и поместим в него какую-то первоначальную последовательность символов:

$ cd shell
/www/live.daemony.org/shell
$ touch randurl
$ echo "blablabla" > randurl

Тут же можно сразу подправить шаблон сайта и сделать вставку URL-ловушки. Я вставил ее в шаблоне темы Wordpress таким образом:

<a title="ВНИМАНИЕ! Если Вы человек, а не робот НЕ НАЖИМАЙТЕ на эту ссылку,
иначе доступ к этому сайту будет для Вас заблокирован приблизительно на 1 час."
href="http://live.daemony.org/<?php include ('/www/live.daemony.org/shell/randurl'); ?>.html">&copy;</a>

Вы эту ссылку можете найти в шапке сайта под заголовком сразу же после описания. Ею обрамлен значек копирайта.

Почему я поступил именно так? Потому что поисковики не любят ссылки, скрытые от глаз посетителя. Кроме того, обычному человеку вряд ли прийдет в голову ткнуть в этот копирайт. Скорее всего, он его даже не заметит. А если даже он и поднесет к нему курсор мыши, то увидит предупреждение.

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

$ cp /www/live.daemony.org/htdocs/.htaccess /www/live.daemony.org/shell/htaccess

В принципе все готово. Приступаем к скриптам

ban_mega_dl.sh [версия 1.0]

---

Эта часть публикации доступна только зарегистрированным посетителям!
Пожалуйста, войдите [Login] или зарегистрируйтесь [Register].

---

blocked_log_rotate.sh

---

Эта часть публикации доступна только зарегистрированным посетителям!
Пожалуйста, войдите [Login] или зарегистрируйтесь [Register].

---

Вот, собственно, и вся реализация. Осталось наши конфиги занести в crontab.

# - Ban scripts for Web-Downloaders -
20           *    *    *    *    daemony /www/live.daemony.org/shell/blocked_log_rotate.sh
*/5          *    *    *    *    daemony /www/live.daemony.org/shell/ban_mega_dl.sh

Касательно того, сколько последних строчек лога шерстить и с каким промежутком во времени - каждому решать индивидуально. Я взял 5000 экспериментально. Многое зависит от посещаемости Вашего сайта.

А для перенаправления тех, кто попал в бан, дабы пояснить людям за что им закрыт доступ я сделал вот такую 403-ю страничку. Зацените!

Перенаправление осуществляется в htaccess таким образом:

    ErrorDocument 403 http://live.daemony.org/leech/403/

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

P.S.: Пока писал публикацию в список забаненных попало три IP адреса. Ребята с Питерского IP: елки-палки! Качать фотогалерею Даунлоуд Мастером - не слишком ли? А?

P.P.S.: По мере тестирования работы скрипта и выявления ошибок, либо написания исправлений и дополнений эта публикация, возможно, будет обновляться.

---

UPD: 2009-04-18 09.00

А вот и первые грабли.

Кривая реализация генерации случайной последовательности ссылки из последней строчки access.log дала о себе знать. Все, кто сегодня в промежуток с 00 часов 00 минут по Киевскому времени по 00 часов 05 минут находились на сайте (или просто держали открытой страничку в браузере) попали в бан на один час. Приношу извинения. Заметил это только утром.

Почему так произошло.

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

UPD: 2009-04-18 17.14

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

rand.sh

---

Эта часть публикации доступна только зарегистрированным посетителям!
Пожалуйста, войдите [Login] или зарегистрируйтесь [Register].

---

Теперь порядок. Кладем скрипт в папку shell/ и придаем скрипту ban_mega_dl.sh следующий вид:

ban_mega_dl.sh [версия 2.0]

---

Эта часть публикации доступна только зарегистрированным посетителям!
Пожалуйста, войдите [Login] или зарегистрируйтесь [Register].

---

Вот. Другое дело. Для генерации случайной последовательности, мы больше не привязаны к логу access.log. Строка, которую генерит awk всегда будет уникальна. Тестируем дальше.

UPD: 2009-04-20 13.47

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

Немного усовершенствовал скрипт, дабы не плодить лишние 404-е ошибки поисковыми ботами из-за отсутствующих страниц - URL-ловушек. Теперь в системе будет постоянно существовать страница со случайным именем. Приводим скрипт blocked_log_rotate.sh к такому виду:

ban_mega_dl.sh [версия 3.0]

---

Эта часть публикации доступна только зарегистрированным посетителям!
Пожалуйста, войдите [Login] или зарегистрируйтесь [Register].

---

Естественно, сразу же после правки скрипта следует создать в системе пустой файл с именем $RANDURL.html, где $RANDURL - будет текущее случайное значение имени URL-ловушки.

В файл $RANDURL.html можно написать какую-нибудь предупреждающую инструкцию для качальщиков. Это уже на Ваше усмотрение.

Похожие публикации

• Пересборка ядра FreeBSD
• BlogJet
• Мониторилка PPPoE
• Таблица вычисления Google Pagerank
• Web сервер Apache 1.3 с поддержкой php5 и mod_perl (русский перевод httpd.conf)
• Галерея “Искусство”
• FreeBSD 7.0 Release Candidate 3
• savecore: reboot after panic: page fault
• Что нового в релизе FreeBSD 7.0
• Перенос FreeBSD на другой жесткий диск