Как защитить файлы на сайте от скачивания
Зачем массово качаются сайты? Сходу можно указать две причины. Кому-то Ваш сайт очень понравился и этот "кто-то" нашел на нем много полезной для себя информации. Вот и хочется человеку сделать себе локальное "зеркало" этого сайта, для того, чтобы не выходя в Интернет как следует изучить информацию на нем.
В другом случае кто-то также нашел сайт интересным, но не в плане информативности, а в плане заработка. Такие субъекты, массово выкачивая сайты со структурой каталогов, медиа-контентом и прочим содержимым, создают потом "зеркала" этого сайта в Сети на каком-то ином хостинге, а проще говоря, крадут сайт целиком чтобы на этом потом заработать.
Уверен, что ни одному владельцу сайта не будет легче ни от первой причины, ни, тем более, от второй, когда его сайт начинают копировать подчистую. Как минимум, это процесс доставляет технические неудобства. Появляется излишняя нагрузка на сервер, расходуется излишний трафик, а если трафик этот в лимите, то еще и излишние деньги за превышение лимита трафика. Обычно веб-мастера, видя как нещадно с их сайта выгружаются один за одним страницы со скоростью, с которой нормальный человек не может серфить по сайту, опускают руки и оставляют все на самотек. Ведь если посмотреть с другой стороны, как-бы если твой сайт кто-то решил скопировать, значит он у тебя действительно полезен. Можно вроде бы этим гордиться?
Нет. Гордость отодвинем на второе место. Ведь мы же не станем гордиться, если у нас угонят машину, думая, какая же классная была она у нас, раз ее решили угнать. Будем пытаться защищаться.
Но, от воровства контента 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 такого "посетителя" на определенное время или навсегда.
Я хочу поделиться своим примером защиты от скачивания, который реализовал сегодня на этом сайте. Не исключено, что чем-то он может показаться Вам "кривым", в чем-то неоптимальным (я имею в виду сами скрипты). Что-ж, я буду рад выслушать в комментариях Ваши дополнения и предложения. А вот если мой пример принесет Вам практическую пользу, я за Вас порадуюсь. У меня пока что система работает в режиме тестирования.
Начнем с того, что еще раз охарактеризуем нашего потенциального враждебного посетителя и последовательно поставим задачу.
- Программа - робот, а не человек, поэтому, при потоковом скачивании сайта она проходит по всем ссылкам на страницах, которые находит в HTML коде, в отличии от человека разумного . Программа может не проходить по JavaScript ссылкам - и в 99% случаев так и есть (в качалках обычно JavaScripts не поддерживается), но нам это не нужно.
- Следует учесть, что программа может быть настроена таким образом, чтобы не проходить по заданным пользователем URL'ам.
- Пользователи качалок могут настроить программу не переходить и не качать страницы по внешним ссылкам, но в подавляющем большинстве случаев они будут настраивать программу для скачивания файлов по ВСЕМ ВНУТРЕННИМ ссылкам. Ведь они собираются скачать Ваш сайт.
- Пользователь, запустивший качалку, может иметь динамический IP адрес, а следовательно, забанив его мы в будущем можем "наказать" ни в чем не повинную третью сторону. Поэтому бан следует устанавливать временно, но все же хранить старые логи, с целью выявления "рецидивистов" и применения соответствующего (более жестокого) наказания.
Последовательность реализации
- Согласно характеристике враждебного посетителя, программа-качалка при попытке загрузить сайт, пройдет по ссылкам сайта, которые найдет в HTML коде первой попавшейся страницы и так далее, до той глубины вложенности, которую задал ей пользователь. Задействуем URL ловушку на каждой странице сайта, скрыв ее от обычного пользователя. Программе такой URL будет доступен. URL будет установлен в header шаблона сайта, поскольку он вызывается при генерации каждой страницы. Также вполне стоит вставить URL ловушку в других частях шаблона: боковой колонке, подошве и т.п.
- Анализируя по cron 'у последние N строк файла access.log сервера Apache, выберем IP адреса тех, кто прошел по URL ловушке и поместим эти IP в специальный лог-файл, а следом и в .htaccess с директивой " Deny from ".
- При реализации пункта 1 следует учесть случай, когда наш сайт приходит качать продвинутый юзер, знающий, что на нашем сайте стоит защита от скачивания и знающий по какому URL проходить нельзя, дабы не попасть в бан лист. Такой юзер заранее может настроить программу не проходить по такому URL, следовательно, защитный URL следует сделать ДИНАМИЧЕСКИ изменяющимся.
- При реализации всей схемы нельзя забывать про поисковых роботов Google, Yandex и т.п. Ведь их банить нельзя, а действовать они будут так же как и программа-качалка. Поэтому, следует продумать механизм отличения роботов поисковых систем, от программ качалок.
Задача поддается реализации с использованием стандартных средств ОС FreeBSD, либо другой Unix-like системы.
Всего мне пришлось написать два скрипта. Первый скрипт я буду запускать по cron раз в пять минут. Он будет проверять последние, допустим, 5000 строк файла access.log на предмет "интересной" ссылки и, в случае ее нахождения, реагировать соответствующе. Второй скрипт будет вызываться раз в час (например, на 20-й минуте часа) и, в случае если за последний час был кто-то пойман, архивировать имеющиеся данные, очищать текущий список заблокированных хостов и отправлять администратору уведомление со списком забаненных.
Обратите внимание на права доступа. Я сделал каталог shell доступным для пользователя www, потому что в нем будет храниться файл с URL-ловушкой, который будет инклюдиться в PHP шаблон сайта. Создадим, собственно, сам файл и поместим в него какую-то первоначальную последовательность символов:
Вы эту ссылку можете найти в шапке сайта под заголовком сразу же после описания. Ею обрамлен значек копирайта.
Почему я поступил именно так? Потому что поисковики не любят ссылки, скрытые от глаз посетителя. Кроме того, обычному человеку вряд ли прийдет в голову ткнуть в этот копирайт. Скорее всего, он его даже не заметит. А если даже он и поднесет к нему курсор мыши, то увидит предупреждение.
Следующим шагом, что я посчитал нужным сделать - это сохранить свой текущий .htaccess файл. Это оказалось не лишним, поскольку пока я экспериментировал со скриптами, обнулил свой (достаточно немаленький) .htaccess несколько раз. Собственно поэтому теперь и Вам советую: сделайте бекап .htaccess! Более того, по моей схеме постоянное содержимое .htaccess будет храниться в другом файле, а в сам .htaccess будет каждый раз записываться новая информация.
В принципе все готово. Приступаем к скриптам
ban_mega_dl.sh [версия 1.0]
blocked_log_rotate.sh
Вот, собственно, и вся реализация. Осталось наши конфиги занести в crontab .
Касательно того, сколько последних строчек лога шерстить и с каким промежутком во времени - каждому решать индивидуально. Я взял 5000 экспериментально. Многое зависит от посещаемости Вашего сайта.
А для перенаправления тех, кто попал в бан, дабы пояснить людям за что им закрыт доступ я сделал своя 403-ю страничку.
Перенаправление осуществляется в htaccess таким образом:
Повторюсь снова. Возможно, все это Вам покажется усложненным - я буду рад выслушать от Вас более оптимальные на Ваш взгляд варианты. А пока что, описанная здесь система работает.
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
Теперь порядок. Кладем скрипт в папку shell/ и придаем скрипту ban_mega_dl.sh следующий вид:
ban_mega_dl.sh [версия 2.0]
Вот. Другое дело. Для генерации случайной последовательности, мы больше не привязаны к логу access.log . Строка, которую генерит awk всегда будет уникальна. Тестируем дальше.
UPD: 2009-04-20 13.47
Третий день, полет нормальный. За это время попало в ловушку три хоста и ручной анализ логов говорит о том, что не просто так - действительно с заблокированных хостов предпринимались попытки автоматического скачивания страниц сайта. Новых поисковых ботов (кроме тех, что уже внесены в исключения) не выявлено.
Немного усовершенствовал скрипт, дабы не плодить лишние 404-е ошибки поисковыми ботами из-за отсутствующих страниц - URL-ловушек. Теперь в системе будет постоянно существовать страница со случайным именем. Приводим скрипт blocked_log_rotate.sh к такому виду:
ban_mega_dl.sh [версия 3.0]
Естественно, сразу же после правки скрипта следует создать в системе пустой файл с именем $RANDURL.html , где $RANDURL - будет текущее случайное значение имени URL-ловушки.
В файл $RANDURL.html можно написать какую-нибудь предупреждающую инструкцию для качальщиков. Это уже на Ваше усмотрение.
ДОПОЛНЕНИЕ
Вам надоели люди, которые размещают картинки, опубликованные на вашем сайте - на своих ресурсах, тем самым расходуя ваш траффик и создавая ненужную нагрузку на ваш хостинг? Данный код, размещенный в конца вашего файла .htaccess, позволит предотвратить загрузку ваших изображений - сторонними сайтами.
Защита файлов на сервере от прямых ссылок (antileech)
Защита от скачивания файлов по прямым ссылкам, или как ее еще называют "антилич-защита" - задача не менее важная, чем защита остального контента сайта. Грамотно сделанная система защиты от прямых ссылок позволит разграничивать доступ к файлам разным категориям пользователей, вести подробную статистику скачиваний, скрывать истинное место размещения файлов, а также привлечет новых посетителей на ваш сайт. А то обычно получается так, что сторонние сайты публикуют прямую ссылку на файл, размещенный на вашем сервере, они получают посетителей, рейтинги, стригут купоны с рекламы, а вы получаете только счета за трафик. Справедливое разделение? Нет. В последнее время появилось огромное количество файлообменных сервисов, и на каждом из них используется своя система антилич-защиты, где-то более удачно реализованная, где-то менее. За счет этого они имеют возможность регулировать скорость отдачи файлов премиум-пользователям и халявщиками, определять лимит на скачивание по времени, поддерживать или не поддерживать докачку и т.д. В этой статье я расскажу о самом принципе построения антилич-системы, а также приведу пример простейшего, но вполне работоспособного скрипта.
Сперва начнем с изучения предмета. Посмотрим лог работы какого-нибудь менеджера закачки, который скачивает обычный файл с обычного web-сервера. Конкретно нас интересуют служебные заголовки, которые сервер отдает менеджеру закачки или браузеру:
Напишем простейший скрипт и попробуем открыть его в браузере или добавим ссылку на него в менеджер закачек:
- <?
- Header ( "HTTP/1.1 200 OK" );
- Header ( "Connection: close" );
- Header ( "Content-Type: application/octet-stream" );
- Header ( "Accept-Ranges: bytes" );
- Header ( "Content-Disposition: Attachment; filename=filename.dat" );
- Header ( "Content-Length: 50000" );
- echo str_repeat ( '!' , 50000 );
- ?>
В любом случае начнется скачивание файла filename.dat размером 50000 байт, состоящего из восклицательных знаков. Мы только что "на лету" сгенерировали файл, которого физически на сервере не существует. Таким образом мы можем генерировать "виртуальные" файлы и отдавать их пользователю. Это могут быть, например, созданные скриптами CSV-файлы, картинки, архивы, сгенерированные PDF-файлы и другой контент. Тут главное правильно указывать имя файла и размер передаваемых данных, тип рекомендуется всегда оставлять application/octet-stream. Главный недостаток этого способа в том, что не поддерживается докачка в случае обрыва соединения, но он лучше всего подходит для небольших, до нескольких сот килобайт, файлов.
Теперь немного усложним задачу и модифицируем скрипт для работы с реальными файлами. Принцип тут тот же самый, только данные будут создаваться не из воздуха, а читаться из файла. Пусть сами файлы лежат в подпапке \secret_data, а имя файла передается в качестве параметра вызова скрипта.
Ссылка на закачку в этом случае будет выглядеть примерно так:
Осталось решить последнюю проблему с поддержкой докачки. Снова посмотрим лог менеджера закачки, но на этот раз будем смотреть не ответы сервера, а запросы, передаваемые ему для продолжения закачки:
RewriteEngine on
Options +FollowSymlinks
RewriteRule ^download\/(.*)$ getfile.php?fname=$1 [L]
И ссылка преобразуется в уже знакомую нам
Options -Indexes
Deny from all
После этого даже если злоумышленник узнает имя секретной папки, то все равно не сможет ничего скачать из нее по прямым ссылкам или просмотреть ее содержимое. Вот теперь все готово для создания своего файлообменника с нужными вам опциями защиты и разграничениями прав. Не забывайте выполнять все необходимые проверки, чтобы через скрипт закачки злоумышленники не смогли совершить атаку на сервер. Также имейте в виду, что подобные системы создают нехилую нагрузку, поэтому для больших объемов данных все-таки придется обзавестись выделенным сервером.
В приложении рабочий скрипт антилича из этой статьи с настроенной структурой папок. Запускать его, естественно, надо только на локальном или удаленном web-сервере с поддержкой mod_rewrite и .htaccess
Предположим, вы всё же приняли правильное решение конкретно в вашей ситуации о том, что вам следует ограничить доступ к определенному контенту.
Какой тип контента вы хотите защитить?
- видеофайлы
- целую папку или раздел на сервере
- скачивание изображений
- текст от копирования
Защита видео с помощью плагина Secure Html 5 Video Player
Но для начала давайте остановимся и обсудим для чего нужен это плагин.
Он будет вам полезен, если вы хотите ограничить доступ к просмотру видео, которое вы загружаете и храните непосредственно на вашем сервере.
Как это работает?
В настройках плагина вы задаете папку-каталог, где будут храниться ваши файлы:
Теперь, ваше видео будет доступно для просмотра только в том случае, если у пользователя есть доступ к странице, на которой оно размещено.
У плагина Secure Html 5 Video Player есть большой ряд других настроек. Вы можете просмотреть их самостоятельно. Обратите внимание на страницу помощи (Help). В ней вы найдете шорткоды для вставки видео и примеры использования.
После того, как вы загрузили ваше видео в указанную папку, вы можете вывести его на любую страницу с помощью простого шорткода:
* расширение файла не нужно указывать.*
Как создать защищенный раздел на сайте
Вот пример скриншота настройки, где вам просто нужно указать путь к папке на сервере.
Теперь вы можете кидать туда любые файлы, страницы, даже целые разделы, и они будут доступны только тем пользователям, которые знают пароль доступа.
Что если у вас нет опции защиты каталога паролем? Может быть, вы вообще не используете панель управления? Что делать в этом случае? Читайте дальше, как настроить аутентификацию к засекреченным разделам вашего сайта через .htaccess.
Защита каталога с помощью .htaccess и .htpasswd
- Загрузите оба файла в корень защищаемого каталога.
Теперь, при переходе в защищенный раздел, браузер предложит небольшую форму для аутентификации, не пройдя которую нельзя будет получить доступ к ресурсам.
Как защитить контент от скачивания и копирования
Сделать это можно буквально в два клика с помощью плагина WP Content Copy Protection & No Right Click
Вначале, убедитесь, действительно ли вам это надо. Многим пользователям не нравится отсутствие возможности скопировать информацию или часть из нее на будущее использование. Поэтому не ограничивайте доступ без нужды!
Если в вашем случае это действительно необходимо, скачайте, установите и активируйте предложенный плагин.
Он включит для вас следующие возможности:
Не спешите ограничивать копирование с сайта. Прочитайте следующий раздел.
Копирование вместе с ссылкой на источник
В этом случае, распространение информации с вашего сайта не только не вредит, но действительно приносит пользу!
Я отыскал несколько плагинов для этой цели. Выбирайте.
Мне не довелось их протестировать. Но я думаю, любой из них будет выполнять свою задачу.
Пожалуй, последний способ защиты контента является здравым способом сохранения контента от копирования.
Файл .htaccess (Hypertext Access) это файл настройки Apache-сервера. В Сети довольно много статей по настройке .htaccess. Этому даже посвящены целые сайты. Однако, когда я приступал к изучению мануалов по настройке файла .htaccess, я мало что понял, уж очень запутано пишут. К тому же вопросам безопасности сайта уделяется мало внимания.
Создаем .htaccess
.htaccess — это обычный текстовый файл, правда с необычным расширением. На хостингах, с которыми я работал, есть возможность создавать и управлять файлом .htaccess прямо из панели управления сайтом. Если же на вашем хостинге такой поддержки нет, вам следует создать текстовый файл с расширением .htaccess у себя на компьютере (например в блокноте) и через FTP-соединение загрузить его в корневую директорию. Действие файла-конфигуратора распространяется на все вложенные директории. Чтобы изменить настройки для определенной директории (например, admin) следует разместить там другой файл .htaccess с новыми настройками.
Первое, что необходимо сделать, это включить перенаправления на основной домен сайта, то есть определиться с доступом к сайту с www или без, а также убрать все index.php. Это нужно для правильной индексации сайта, ведь без этого ваш сайт будет доступен по четырем адресам:
Прячем расширения файлов
Для того, чтобы усложнить процессы нахождения уязвимостей ваших скриптов (а они есть всегда) следует прятать расширения или изменять их на другие, с целью запутать атакующего. Это позволяет сразу же отсечь множество мелких вредителей и увеличить безопасность сайта.
Но это не всегда удобно. Ведь если у мы передаем GET-параметры в URL, запрос будет выглядеть так:
Для этого необходимо изменить всю строку запроса, чтобы не выделять параметры так очевидно. Это называется Человеко-Понятный URL (ЧПУ).
Прячем GET-параметры в ЧПУ
В любой CMS вы можете это сделать в панели администрирования, но если вы не пользуетесь системами управления контентом и делаете все своими руками, как я, писать ЧПУ придется через .htaccess.
Допустим у нас есть catalog.php. В него мы передаем title и year. В нашем случае ссылка выглядит так:
А нам надо преобразовать URL к следующему виду:
Теперь, введите в адресную строку браузера catalog/2011/example.cgi и вы попадеете на catalog.php?year=2011&title=example (чтобы увидеть редирект поставьте [R]). После таких преобразований все ваши ссылки на сайте должны быть приведены к такому виду. Надеюсь пример понятен, а если нет, то пишите комментарии, разберемся.
Управляем выводом ошибок
Отображение ошибок безусловно полезная вещь при отладке приложения. Однако после отладки директивы error_reporting и display_errors следует отключать, потому что атакующий может узнать из них важную информацию о работе скрипта.
Запрещаем доступ к определенным файлам
Чтобы файл, в котором содержится реквизиты доступа к базе данных или файл с паролями, не был прочитан, нужно запретить к нему доступ.
Запрет доступа к директории
Для запрета доступа к целой директории необходимо создать в ней файл .htaccess со следующим содержанием:
Иногда нужно запретить доступ к директории всем кроме определенных ip-адресов. Это можно сделать для защиты административной части сайта.
Аутентификация пользователя
Для защиты административной части сайта следует использовать базовую аутентификацию. Это также можно сделать из панели управления сайтом на хостинге.
Файл .htpasswd содержит имена пользователей и хеш пароля. Он создается с помощью утилиты htpasswd.exe и располагается в корневой директории. Теперь, при доступе к защищенной директории пользователь увидит:
Обратите внимание на предупреждение, что пароль будет передаваться в незашифрованном виде. Это значит, что при определенных обстоятельствах он может быть перехвачен. Не используйте данный вид аутентификации для защиты чрезвычайно важных данных.
Защита файлов от скачивания (hotlink)
Читайте также: