Не далее, как пару недель назад, возникла неприятная ситуация с защитой данных на блоге. После опубликования второй части закрытого отчёта по VladimirFX, неожиданно выяснилось, что хотлинк-защита на блоге не работает, и закачка медиа-файлов (изображения, видео) возможна по прямым ссылкам, а так же — размещение их на других ресурсах.

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

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

Итак, защищаем данные на блоге от посягательства!

Настраиваем hotlink-защиту от прямых ссылок

Хотлинк (англ.hotlink) — включение в веб-страницу файлов-изображений или других ресурсов с чужого сервера.

Другими словами, если какой то мерзавец размещает у себя на  странице ваши изображения или медиа-файлы — то при загрузке его страниц, файлы закачиваются с вашего сервера, и таким образом, вы оплачиваете его трафик, ну или — он ворует ваш.

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

Немного теории. Как реализуется хотлинк-защита: через проверку переменной HTTP_REFERER (например, через директивы вебсервера Apache в модуле mod_rewrite) на сервере. Проще говоря, переменная HTTP_REFERER содержит имя хоста, с которого происходит запрос на загрузку файла.

Если HTTP_REFERER не совпадает с именем своего сервера или списком разрешённых хостов, то посетителю может выдаваться другое изображение, или он может перенаправляться на URL-заглушку.

Прописываются правила хотлинк-защиты в файл конфигурации веб-сервера (httpd.conf) — если у вас выделенный физический или виртуальный сервер; или в локальный файл конфигурации хоста (.htaccess) — если используется виртуальный хостинг.

Так как подавляющее большинство блоговодов используют виртуальный хостинг, то рассматривать мы будем последний вариант.

По умолчанию, хотлинк-защиту можно настроить и включить через панель управления хостингом, в моём конкретном случае — через cPanel. Для этого, в модуле «Безопасность» надо перейти в раздел «защита от прямых ссылок«.

хотлинк-защита

hotlink-защита

Здесь мы, прежде всего, включаем саму функцию хотлинк-зашиты, нажимая кнопку «включить». Далее, в текстовом поле «Разрешить доступ к URL-адресам» прописываем имена ВСЕХ хостов, с которых РАЗРЕШЕНА загрузка файлов, а именно: имя собственного хоста, имена хостов поисковиков (Яндекс, Google) и соц. сетей.

Это необходимо для того, что бы ваш собственный сайт мог грузить картинки, поисковики индексировали ваши картинки, и выдавали их в результатах поиска по изображениям, а в соц. сетях размещались бы анонсы ваших статей, вместе с превью-изображениями. Так же, можете добавить имена дружественных сайтов. URL прописывается вместе с протоколом: http:// или https://

Далее, в разделе «Разрешённые расширения» через запятую прописываются расширения файлов, которые необходимо защитить. К вышеперечисленным на изображении я бы добавил расширения .zip, .rar, .mp4 и .flv — для защиты архивов и видео-контента.

Чек-бокс «разрешить прямые запросы» включает или выключает возможность загрузки файлов по прямым ссылкам — т.е., при вводе прямой ссылки на файл в адресную строку браузера.

В поле «URL-адрес для перенаправления» можно указать ссылку на страницу, на которую будет переадресовываться браузер, при переходе по прямой ссылке, либо ссылку на изображение-заглушку, которое будет выводится при загрузке изображений с чужого хоста.

После прописывания всех настроек нажимаем кнопку «отправить«, и cPanel прописывает команды и правила хотлинк-защиты в локальном файле .htaccess, расположенном в корневом каталоге web-содержимого хостинга, в нашем конкретном случае — /public_html.

И вот тут то кроется основная ЗАСАДА!!!

Как потом выяснилось, даже после настройки через cPanel, хотлинк-защита НЕ РАБОТАЛА. Вся проблема в том, что если в хостинг-плане предусмотрено НЕСКОЛЬКО ДОМЕНОВ, точнее — несколько сайтов с разными доменами второго уровня (на моём хостинг-плане — 5) — то правила, прописанные в корневой web-директории /public_html НЕ РАСПРОСТРАНЯЮТСЯ на подкаталоги с сайтами.

Т.е. — правила защиты должны быть прописаны в файле .htaccess, расположенном НЕ В КОРНЕ хостинга, а в КОРНЕ КАЖДОГО ОТДЕЛЬНОГО САЙТА.

Таким образом, необходимо создать .htaccess в подкаталоге каждого сайта, и уже в нём прописывать правила хотлинк-защиты. Т.к. cPanel этого делать НЕ УМЕЕТ — она приписывает правила только в .htaccess В КОРНЕ ХОСТИНГА — то нам придётся делать это вручную, через ftp-клиент, ЛИБО — через диспетчер файлов, в консоли управления хостингом, т.е. — cPanel.

хотлинк-защита

Открываем файл .htaccess, расположенный в корне хостинга — web-каталоге /public_html, и копируем оттуда команды hotlink-защиты:

RewriteCond %{HTTP_REFERER} !^http://direct-market.ru/.*$      [NC]
RewriteCond %{HTTP_REFERER} !^http://direct-market.ru$      [NC]
RewriteCond %{HTTP_REFERER} !^http://go.mail.ru/.*$      [NC]
RewriteCond %{HTTP_REFERER} !^http://go.mail.ru$      [NC]
RewriteCond %{HTTP_REFERER} !^http://images.rambler.ru/.*$      [NC]
RewriteCond %{HTTP_REFERER} !^http://images.rambler.ru$      [NC]
RewriteCond %{HTTP_REFERER} !^http://images.yandex.ru/.*$      [NC]
RewriteCond %{HTTP_REFERER} !^http://images.yandex.ru$      [NC]
RewriteCond %{HTTP_REFERER} !^http://images.yandex.ua/.*$      [NC]
RewriteCond %{HTTP_REFERER} !^http://images.yandex.ua$      [NC]
RewriteCond %{HTTP_REFERER} !^http://mail.ru/.*$      [NC]
RewriteCond %{HTTP_REFERER} !^http://mail.ru$      [NC]
RewriteCond %{HTTP_REFERER} !^http://my.mail.ru/.*$      [NC]
RewriteCond %{HTTP_REFERER} !^http://my.mail.ru$      [NC]
RewriteCond %{HTTP_REFERER} !^http://rambler.ru/.*$      [NC]
RewriteCond %{HTTP_REFERER} !^http://rambler.ru$      [NC]
RewriteCond %{HTTP_REFERER} !^http://www.google.by/.*$      [NC]
RewriteCond %{HTTP_REFERER} !^http://www.google.by$      [NC]
RewriteCond %{HTTP_REFERER} !^http://www.google.com/.*$      [NC]
RewriteCond %{HTTP_REFERER} !^http://www.google.com$      [NC]
RewriteCond %{HTTP_REFERER} !^http://www.google.com.ua/.*$      [NC]
RewriteCond %{HTTP_REFERER} !^http://www.google.com.ua$      [NC]
RewriteCond %{HTTP_REFERER} !^http://www.google.ru/.*$      [NC]
RewriteCond %{HTTP_REFERER} !^http://www.google.ru$      [NC]
RewriteCond %{HTTP_REFERER} !^http://www.odnoklassniki.ru/.*$      [NC]
RewriteCond %{HTTP_REFERER} !^http://www.odnoklassniki.ru$      [NC]
RewriteCond %{HTTP_REFERER} !^http://yandex.ru/.*$      [NC]
RewriteCond %{HTTP_REFERER} !^http://yandex.ru$      [NC]
RewriteCond %{HTTP_REFERER} !^https://www.google.ru/.*$      [NC]
RewriteRule .*\.(jpg|jpeg|gif|png|bmp|mp4|rar|zip)$ http://direct-market.ru/stati.html [R,NC]

Первый две строчки — указываем в качестве рефера свой хост, в моём случае — http://direct-market.ru/. Все остальные строчки — хосты поисковиков и соц. сетей, а так же — хосты дружественных сайтов, для которых вы разрешаете использовать ваши файлы.

Последняя строчка — перечисление защищаемых расширений, и адрес URL редиректа — на который будет перенаправляться юзер, при переходе по прямой ссылке на защищённый файл.

После этого, копируем эти правила в .htaccess, расположенный в поддиректории каждого отдельного сайта. На этом — всё, финиш. Настройка хотлинк-защиты завершена. Теперь ни один мерзавец не сможет «подсосаться» к вашему трафику, или выкладывать ваши файлы и изображения, на своём сайте, как свои собственные.

Защищаем каталоги с файлами от просмотра и доступа

Есть в движке WordPress такая особенность, сопоставимая с реальной проблемой, которую можно назвать самой настоящей уязвимостью.

При загрузке медиа-файлов, через панель администратора, в библиотеку файлов, движок создаёт новые директории, в подкаталоге /wp-content/uploads/. Эти директории рассортированы по годам, точнее — носят имена 2010, 2011, 2012, 2013 и т.д. А в них соответственно — каталоги по месяцам — 01, 02, 03, и т.д.

И уже в этих подкаталогах, расположены загруженные медиа-файлы. Так вот, при попытке доступа к такому каталогу, по прямой ссылке из браузера, можем наблюдать такое вот безобразие:

1

А всё потому, что в поддиректории с файлами НЕТ ИНДЕКСНОГО ФАЙЛА (!!!) index.html или index.php, который сервер ищет в первую очередь. Если такой файл НЕ находится — то сервер вываливает напоказ всё его содержимое.

Если честно — я был просто в шоке, когда это узнал!

Лечится это довольно легко: в подкаталоге создаётся два файла:

  • Пустой файл index.html
  • и файл .htaccess, в котором прописывается команда — DirectoryIndex index.php index.html

Таким образом, сервер принудительно отсылается к index.html, который и показывается юзеру в браузере, при попытке заглянуть в каталог. То есть, браузер показывает просто пустую страницу.

С этим тоже разобрались.

Защита контента на страницах от копирования

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

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

А если её ещё и поисковик первой проиндексировал, и разместил в ТОПе, а ваш первоисточник — посчитал дублем и спамом — тот тут вообще нет предела разочарованию и раздражению!!!

Выход из ситуации (но не панацея!!!) — плагин WP-CopyProtect. Что делает плагин: запрещает выделять фрагменты текста на странице, и отключает правый клик мыши, благодаря размещению в заголовке страниц java-скрипта.

Ссылка на страницу плагина: http://wordpress.org/extend/plugins/wp-copyprotect/

Настройки плагина просты, как день:

copyprotect

Хоть они и на английском — ошибиться очень трудно:

  • Disable right mouse click: — включает/выключает правый клик мыши, с предупреждающим тесктом/без текста;
  • Disable text selection: — включает/выключает выделение текста на странице;
  • Display protection information: — включает выключает добавление информации о копирайте;

Очевидные недостатки плагина:

Включает защиту АБСОЛЮТНО НА ВСЕХ СТРАНИЦАХ БЛОГА, без разбора, и без возможности сортировки. Так же — абсолютно для всех ролей пользователей, в т.ч. — и для админа.

При написании новых статей, новостей и постов мне часто приходится копипастить информацию с других страниц, поэтому я просто ЗАПАРИЛСЯ его включать/выключать, поэтому — выключил его вообще.

Есть вариант переработать плагин, точнее — вытащить из него java-скрипт, выключающий выделение и правый клик, и разместить его непосредственно в шаблоне темы оформления header.php, в заголовке страниц. А для избирательности — добавить функцию на php, распознающую, какая именно страница загружается. Тогда, защита будет активироваться на строго определённых страницах, указанных в функции в качестве аргумента.

Но, пока что, руки до этого всё никак не дойдут. Если дойдут — сразу же выложу описание.

Желаю вашему блогу долгой и безопасной жизни! С уважением, Дмитрий Жуков.