Защита файла от скачивания

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

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

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

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

Но, от воровства контента 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 , в котором все и будет происходить.

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

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

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

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

Следующим шагом, что я посчитал нужным сделать – это сохранить свой текущий .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-сервера. Конкретно нас интересуют служебные заголовки, которые сервер отдает менеджеру закачки или браузеру:

HTTP/1.1 200 OK
Date: Sat, 15 Aug 2009 17:24:40 GMT
Server: Apache/1.3.41 (Win32)
Connection: close
Content-Type: application/octet-stream
Accept-Ranges: bytes
Content-Disposition: Attachment; filename=filename.rar
Content-Length: 2676708

В заголовках есть вся нужная информация: тип файла, его имя, размер файла. После этого идет непосредственно содержимое файла. Если сервер отдает такие заголовки, значит их точно так же может отдавать и наш PHP-скрипт через функцию header.

Напишем простейший скрипт и попробуем открыть его в браузере или добавим ссылку на него в менеджер закачек:

1. Header ( "HTTP/1.1 200 OK" );
2. Header ( "Connection: close" );
3. Header ( "Content-Type: application/octet-stream" );
4. Header ( "Accept-Ranges: bytes" );
5. Header ( "Content-Disposition: Attachment; filename=filename.dat" );
6. Header ( "Content-Length: 50000" );
7. echo str_repeat ( ‘!’ , 50000 );
8. ?>

В любом случае начнется скачивание файла filename.dat размером 50000 байт, состоящего из восклицательных знаков. Мы только что "на лету" сгенерировали файл, которого физически на сервере не существует. Таким образом мы можем генерировать "виртуальные" файлы и отдавать их пользователю. Это могут быть, например, созданные скриптами CSV-файлы, картинки, архивы, сгенерированные PDF-файлы и другой контент. Тут главное правильно указывать имя файла и размер передаваемых данных, тип рекомендуется всегда оставлять application/octet-stream. Главный недостаток этого способа в том, что не поддерживается докачка в случае обрыва соединения, но он лучше всего подходит для небольших, до нескольких сот килобайт, файлов.

Теперь немного усложним задачу и модифицируем скрипт для работы с реальными файлами. Принцип тут тот же самый, только данные будут создаваться не из воздуха, а читаться из файла. Пусть сами файлы лежат в подпапке secret_data, а имя файла передается в качестве параметра вызова скрипта.

1. $fname = $_GET [ ‘fname’ ];
2. $fsize = filesize ( ‘secret_data/’ . $fname );
3. Header ( "HTTP/1.1 200 OK" );
4. Header ( "Connection: close" );
5. Header ( "Content-Type: application/octet-stream" );
6. Header ( "Accept-Ranges: bytes" );
7. Header ( "Content-Disposition: Attachment; filename=" . $fname );
8. Header ( "Content-Length: " . $fsize );
9. // Открыть файл для чтения и отдавать его частями
10. $f = fopen ( ‘secret_data/’ . $fname , ‘r’ );
11. while (! feof ( $f )) <
12. // Если соединение оборвано, то остановить скрипт
13. if ( connection_aborted ()) <
14. fclose ( $f );
15. break;
16. >
17. echo fread ( $f , 10000 );
18. // Пазуа в 1 секунду. Скорость отдачи 10000 байт/сек
19. sleep ( 1 );
20. >
21. fclose ( $f );
22. ?>

Ссылка на закачку в этом случае будет выглядеть примерно так:

http://server/getfile.php?fname=secret_file.rar

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

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

GET /filename.rar HTTP/1.0
User-Agent: Download Master
Accept: */*
Referer: http://server.com/
Range: bytes=2730210-
Pragma: no-cache
Cache-Control: no-cache
Host: server.com

В поле Range передается смещение от начала файла, с которого начинается или продолжается закачка. На сервере это поле преобразуется в переменную окружения HTTP_RANGE. Чтобы скрипт поддерживал докачку, надо проверять установлена ли эта переменная, и если она имеет непустое значение, то читать файл и отдавать данные с указанной позиции. В этом случае заголовки немного изменятся:

HTTP/1.1 206
Date: Sat, 15 Aug 2009 20:41:27 GMT
Server: Apache/1.3.41 (Win32)
Accept-Ranges: bytes
Connection: close
Content-Disposition: Attachment; filename=filename.rar
Content-Range: bytes 9902214-13807860/13807861
Content-Length: 3905647
Content-Type: application/octet-stream

Добавилось поле Content-Range, показывающее нужный интервал и общий размер файла, а Content-Length содержит размер фрагмента файла от начала запрошенной позиции докачки до конца файла. Продублируем их в нашем скрипте:

1. $fname = $_GET [ ‘fname’ ];
2. $fsize = filesize ( ‘secret_data/’ . $fname );
3. $fdown = ‘secret_data/’ . $fname ;
4. // Установлена или нет переменная HTTP_RANGE
5. if ( getenv ( ‘HTTP_RANGE’ )== "" ) <
6. // Читать и отдавать файл от самого начала
7. $f = fopen ( $fdown , ‘r’ );
8. header ( "HTTP/1.1 200 OK" );
9. header ( "Connection: close" );
10. header ( "Content-Type: application/octet-stream" );
11. header ( "Accept-Ranges: bytes" );
12. header ( "Content-Disposition: Attachment; filename=" . $fname );
13. header ( "Content-Length: " . $fsize );
14. while (! feof ( $f )) <
15. if ( connection_aborted ()) <
16. fclose ( $f );
17. break;
18. >
19. echo fread ( $f , 10000 );
20. sleep ( 1 );
21. >
22. fclose ( $f );
23. >
24. else <
25. // Получить значение переменной HTTP_RANGE
26. preg_match ( "/bytes=(d+)-/" , getenv ( ‘HTTP_RANGE’ ), $m );
27. $csize = $fsize – $m [ 1 ]; // Размер фрагмента
28. $p1 = $fsize – $csize ; // Позиция, с которой начинать чтение файла
29. $p2 = $fsize – 1 ; // Конец фрагмента
30. // Установить позицию чтения в файле
31. $f = fopen ( $fdown , ‘r’ );
32. fseek ( $f , $p1 );
33. header ( "HTTP/1.1 206 Partial Content" );
34. header ( "Connection: close" );
35. header ( "Content-Type: application/octet-stream" );
36. header ( "Accept-Ranges: bytes" );
37. header ( "Content-Disposition: Attachment; filename=" . $fname );
38. header ( "Content-Range: bytes " . $p1 . "-" . $p2 . "/" . $fsize );
39. header ( "Content-Length: " . $csize );
40. while (! feof ( $f )) <
41. if ( connection_aborted ()) <
42. fclose ( $f );
43. break;
44. >
45. echo fread ( $f , 10000 );
46. sleep ( 1 );
47. >
48. fclose ( $f );
49. >
50. ?>

Теперь скрипт поддерживает докачку в случае обрыва связи и закачку файла в несколько потоков. Можно начинать добавлять к нему всякие навороты: например, проверять регистрацию или права доступа пользователя, регулировать количество соединений с одного ip-адреса, поддерживать докачку, изменять скорость отдачи для премиум-пользователей, проверять cookies после посещения основного сайта и все, что только можно придумать. Это я оставляю целиком на вашу фантазию. Последний штрих – преобразование ссылок через файл .htaccess и модуль Apache mod_rewrite. Например, ссылка будет иметь вид:

http://server/download/secret_file.rar

В файле .htaccess прописано правило для mod_rewrite:

RewriteEngine on
Options +FollowSymlinks
RewriteRule ^download/(.*)$ getfile.php?fname=$1 [L]

И ссылка преобразуется в уже знакомую нам

http://server/getfile.php?fname=secret_file.rar

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

Options -Indexes
Deny from all

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

В приложении рабочий скрипт антилича из этой статьи с настроенной структурой папок. Запускать его, естественно, надо только на локальном или удаленном web-сервере с поддержкой mod_rewrite и .htaccess

Antileech Demo

Бывают такие случаи, когда владелец сайта не желает, или не может, отдавать свой сайт целиком своим посетителями.
Как это сделать?

Приведем простой пример:

У вас есть сайт, на котором, вы публикуете обои для рабочего стола. Общий объем сайта — 500mb, посещаемость 7 000 хостов в сутки, примерный трафик — 300Гб в месяц или 10 Гб в день.
Добавим к этим посетителям еще 20 человек, скачавших ваш сайт целиком. Получаем увеличение трафика на 10Гб или в два раза. Или другими словами 0.28% посетителей создали 50% трафика. Не совсем честно, особенно если вы оплачиваете трафик.

Способы защиты сайта от скачивания

1. Запрет по user agent

user agent — так называются данные, которые каждый броузер передает серверу. Эти данные могут содержать в себе такую информацию, как тип броузера, операционная система, список плагинов и многое другое.
Это наиболее простой, но наименее эффективный способ. Его преимущество в том, что ни кого лишнего вы не запретите, а недостаток в том, что практический каждый download агент может маскироваться под стандартные браузеры.

2. Ограничение по количеству просмотренных страниц за определенный промежуток времени.

Тоже достаточно спорный метод. Но надо понимать, что нормальный человек не может просмотреть 60 страниц за 1 минуту. Но с другой стороны и download агент может делать паузы между скачиванием страниц.
Даже если вы не заблокируете download агент совсем, то по крайней мере, сильно затрудните скачивание.

3. Запрет с помощью скрытой ссылки.

Наверное, один из самых правильных методов. Вы должны сделать скрытую ссылку на странице, по которой "живой" человек не перейдет, а download агент и прочие роботы сделают это. ip адрес с которого производится просмотр скрытой страницы блокируется, скажем, на 3 минуты.

Главный недостаток — это то, что вы, таким образом, блокируете поисковых роботов. Бороться с этим можно двумя способами:

* Проверять $http_user_agent. Для этого вам необходимо будет знать то, каким образом подписываются все поисковые роботы. Кроме того, при таком способе download агент сможет замаскироваться под поискового робота. (см. пример 2)
* Запрещать ip адрес можно не по факту загрузки скрытой страницы, а по факту загрузки картинки, установленной на скрытой странице. Поисковые роботы обычно не запрашивают изображения размещенные на страницах, а download агенты обычно делают это.

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

Этот код должен быть установлен на скрытой странице:

Этот код должен быть установлен в верхней части всех страниц сайта:

Пример 2 — не запрещающий известных поисковых роботов.