Добрый день, друзья. Сегодня хочу продолжить цикл публикаций по улучшению любимого движка WordPress, который стал мне, надеюсь, и вам тоже, надежным другом и родителем наших блогов.
Сегодня будет раскрыта очень важная проблема – защищенность. Согласитесь это чуть ли не важнейший аспект ведения дел в сети и не только. Так что рекомендую не пропускать данную публикацию и в обязательном порядке ознакомиться с описанными ниже рекомендациями. И тогда вы сможете спать еще чуточку спокойнее ;) Все без шуток!
В этом посте мы разберем ровно 10 полезных советов о том, как повысить безопасность наших WordPress-блогов различными способами.
Еще до начала описания хотел бы вам посоветовать ознакомиться и с другими моими публикациями на тему улучшения WordPress. Обещаю, что каждый, кому не безразлична судьба родного блога, найдет для себя что-то полезное, важное и интересное.
А теперь разрешите приступить к сегодняшней теме.
1. Убираем ненужную информацию с экрана
Проблема: Когда вы вдруг не можете залогиниться в своем блоге, WordPress выводит некоторую информацию, что об ошибке. Это конечно, хорошо, если вы забыли свой пароль, но так же может быть полезным для того, кто задумал взломать ваш блог! Так почему же не взять и не отключить вывод на экран сообщений об ошибках при входе?
Решение: Чтобы убрать сообщения об ошибке при входе, просто открываем файл functions.php в нашей теме оформления и вставляем в самом начале следующий код:
add_filter('login_errors',create_function('$a', "return null;")); |
Сохраняем и идем проверять. Вот, теперь никаких ошибок ;)
Пояснение: Данный код просто добавляет петлю чтобы переписать функцию login_errors (). Теперь сообщение об ошибке будет выдавать чистый массив, так как функция, которую мы сделали, возвращает пустое значение.
2. Используем SSL
Проблема: Если вы беспокоитесь по поводу того, что данные могут быть перехвачены, то определенно надо начать использовать SSL. Если вдруг вы не знаете что это такое, то SSL – шифрованный протокол обеспечивающий безопасность передачи данных в сетях, таких как Интернет, например.
А знали ли вы что WP можно заставить использовать SSL? Не все хостинги разрешают использовать SSL, но будем надеяться, что ваш поддерживает ;)
Решение: Сперва проверьте, что сервер поддерживает SSL (проще всего спросить у админа, но скорее всего SSL у вас уже включен). Потом откройте файл wp-config.php расположенный в корне (куда установлен сам WordPress и где находится index.php) и вставьте следующий код:
define('FORCE_SSL_ADMIN', true); |
Теперь сохраняем – вот и все готово!
Пояснение: Ну, тут ничего сложного. WordPress имеет кучу регулярных выражений для настройки. В данном же случае мы просто определили FORCE_SSL_ADMIN и присвоили значение true. И как результат движок начал использовать защищенное соединение SSL.
3. Используем .htaccess для защиты файла wp-config
Проблема: Как и любой другой человек, использующий WP для своих проектов, вы должны понимать всю важность файла wp-config.php. Этот файл содержит все данные необходимые для доступа к Базе Данных: имя пользователя, пароль, данные сервера и т.д. Защита wp-config.php крайне необходима, так что как на счет использования возможностей Apache?
Решение: Находим файл .htaccess расположенный в корне (там же где и index.php). На всякий случай создаем копию файла, а то мало ли что… Открываем файл и вставляем следующий код:
<files wp-config.php> order allow,deny deny from all </files> |
Пояснение: .htaccess мощный и лучший инструмент для предотвращения нежелательного доступа к определенным файлам на вашем сервере. В коде выше мы создали правило которое запрещает любые попытки доступа к файлу wp-config.php, так что никакие ацкие демоны не получат к нему доступ!
4. Черный список нежеланных пользователей и ботов
Проблема: Это правило работает как в сети так и в реальной жизни: если кто-нибудь, кто пристает к вам сегодня, скорее всего пристанет к вам и завтра. Знаете ли вы, сколько спам-ботов возвращаются к вам на блог по десять раз на дню, чтобы запостить свои гребаные комменатрии? Решение проблемы очень просто – закроем им доступ на блог!
Решение: Добавляем следующий код в наш .htaccess файл, расположенный в корне:
<Limit GET POST PUT> order allow,deny allow from all deny from 123.456.789 </LIMIT> |
Внимание! Не забудьте поменять 123.456.789 на реальный ip-адрес того, кого хотите заблокировать.
Пояснение: В очередной раз убеждаемся, что Apache мощный инструмент, который в данном случае позволяет нам разрешить доступ к блогу всем, кроме людей или ботов с указанными IP.
Для блокировки нескольких ip-адресов можно использовать следующую запись:
<Limit GET POST PUT> order allow,deny allow from all deny from 123.456.789 deny from 93.121.788 deny from 223.956.789 deny from 128.456.780 </LIMIT> |
5. Защищаем свой WP-блог от инъекций
Проблема: Защита динамического сайта особенно важна. Многие разработчики защищают запросы GET и POST, но иногда этого бывает недостаточно. Мы тоже постараемся защитить свой блог от инъекций и любых попыток изменить PHP переменные GLOBALS и _REQUEST.
Решение: Следующий код будет блокировать инъекции и попытки менять переменные. Следует вставить его в файл .htaccess:
Options +FollowSymLinks RewriteEngine On RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR] RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR] RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2}) RewriteRule ^(.*)$ index.php [F,L] |
Пояснение: Использую возможности .htaccess мы можем проверять запросы. То что мы сделали, проверяет, содержит ли запрос <script> и пытается ли он изменить значение переменных GLOBALS и _REQUEST. Если встречается что-либо подобное, запрос блокируется и выдается 403 ошибка в браузере.
6. Боремся с парсерами и грабберами.
Проблема: Если ваш блог более или менее известен, люди без сомнения попытаются использовать ваш контент на своих сайтах без нашего на то согласия. И одна из бОльших проблем при этом – использование ваших картинок, что влечет за собой увеличение трафика и нагрузки на сервер.
Решение: Для защиты блога против этих злых действий необходимо добавить код в файл .htaccess. Повторюсь – не забывайте делать резервную копию файла.
RewriteEngine On #Replace ?myblog\.ru/ with your blog url RewriteCond %{HTTP_REFERER} !^http://(.+\.)?myblog\.ru/ [NC] RewriteCond %{HTTP_REFERER} !^$ #Replace /images/nohotlink.jpg with your "don't hotlink" image url RewriteRule .*\.(jpe?g|gif|bmp|png)$ /images/nohotlink.jpg [L] |
После вышеописанный действий, только ваш веб-сервер сможет использовать ссылки на ваши изображения, или, что еще более правильно, тот, кто решит использовать изображения с вашего сервера будет вынужден сперва сохранить их, а потом загрузить на свой сервер, что усложняет воровство и увеличивает время.
На сайтах, которые будут ссылаться на ваши картинки, автоматически будет показано изображение nohotlink.jpg. Будьте внимательны, необходимо заранее подготовить данную картинку, чтобы она отображалась на сайтах негодяев =)
Пояснение: С помощью данного кода, первое, что мы сделали это проверку реферрера (referrer) на соответствие URL’у нашего блога и что он не пустой. Если это не так и запрашиваемый файл имеет расширение JPG, GIF, BMP или PNG, вместо него отобразится картинка-пустышка.
7. Создаем плагин для защиты нашего блога от вредоносных URL-запросов
Проблема: Хакеры и прочие злыдни часто используют всякие недобрые запросы для поиска узких мест и атаки. WordPress имеет неплохую изначальную защиту, но совершенству нет предела!
Решение: Создаем текстовый файл и добавляем в него следующий код. Сохраняем файл под именем blockbadqueries.php. После этого загружаем его в директорию wp-content/plugins и активируем наш плагин через админку как и любой другой. Теперь наш блог защищен от вредоносных запросов.
<?php /* Plugin Name: Block Bad Queries Plugin URI: http://perishablepress.com/press/2009/12/22/protect-wordpress-against-malicious-url-requests/ Description: Protect WordPress Against Malicious URL Requests Author URI: http://perishablepress.com/ Author: Perishable Press Version: 1.0 */ global $user_ID; if($user_ID) { if(!current_user_can('level_10')) { if (strlen($_SERVER['REQUEST_URI']) > 255 || strpos($_SERVER['REQUEST_URI'], "eval(") || strpos($_SERVER['REQUEST_URI'], "CONCAT") || strpos($_SERVER['REQUEST_URI'], "UNION+SELECT") || strpos($_SERVER['REQUEST_URI'], "base64")) { @header("HTTP/1.1 414 Request-URI Too Long"); @header("Status: 414 Request-URI Too Long"); @header("Connection: Close"); @exit; } } } ?> |
Пояснение: Данный код достаточно прост. Он проверяет чрезмерно длинные запросы (больше чем 255 символов) и проверяет присутствие в них eval или base64 php-функций в URI. Если выполняется одно из условий, плагин отправляет 414 ошибку (кто не знает: 414 Request-URI Too Long (Запрашиваемый URI слишком длинный)).
8. Удаляем номер версии движка…я серьезно ;)
Проблема: Как вы, наверное, знаете, WordPress автоматически отображает текущую версию движка, которую вы используете. Это небезопасно если вы оперативно не обновляетесь до актуальной версии (хоть это и строго рекомендуется разработчиками, но признайтесь, мы все этим грешим). Вот поэтому стоит усложнить хакерам жизнь!
Решение: Добавьте следующую строку в файл functions.php вашей темы оформления. Сохраняем, обновляем страницу и вуаля – нет больше номера версии.
remove_action('wp_head', 'wp_generator'); |
9. Изменяем стандартное имя администратора «admin»
Проблема: Брутфорс – один из простейших способов сломать пароль. Метод просто: пробовать использовать случайные пароли так много раз, сколько возможно до тех пор, пока правильный не будет найден. Для брутфорса используются словари дающие множество различных комбинаций паролей.
Но зная логин определенно намного легче подобрать правильную комбинацию логин-пароль. Вот поэтому и надо менять стандартный «admin» на что-нибудь посложнее.
Кстати, WordPress 3.0 позволяет менять имя через админку. Следовательно, этот пункт важен, если вы используете старую версию WP и старый «admin» аккаунт.
Решение: Достаточно просто запустить следующий SQL запрос для вашей БД, например через phpMyAdmin:
UPDATE wp_users SET user_login = 'NewUsername' WHERE user_login = 'Admin'; |
10. Предотвращаем прямой просмотр директорий
Проблема: По умолчанию большинство хостингов позволяют листинг директорий. Так, например, если ввести blogname.ru/wp-includes в браузере можно увидеть файлы директории. Это потенциальный риск опасности.
Решение: Просто добавьте следующую строчку в конфигурацию Apache или в .htaccess файл:
Options -Indexes |
Пояснение: Имейте ввиду, что это не тоже самое, что добавление Disallow: /wp* в файл robots.txt. Это не запретит индексацию директории, а запретит юзерам просмотр.
Вдохновение взялось отсюда: 10 Useful WordPress Security Tweaks
Надеюсь, что вы, дорогие читатели, не просто прочитаете это, но еще и примените на практике данные советы. Так же надеюсь на ваши ретвиты — пусть больше народу узнает о данной публикации и будут чувствовать себя спокойнее.
Желаю вам удачи, и пусть ваши проекты не подвергаются взломам и прочим невзгодам.
Реально хороший и полезный пост. Честно говоря, подчерпнул для себя много нового в плане работы с htaccess. Сейчас сделаю ретвит, пусть другие тоже защищаются.
Реально толковая статья. Как раз в тему. Сделал новый блог и думал о защите, а тут статья — спасибо Алычу. Делаю ретвит.
Кажется на хабре была недавно такая же статья...
Тебе всего лишь кажется =)
Если честно, то не похоже — http://habrahabr.ru/blogs/wordpress/98083/
Я не упрекаю кого-то, просто странно вышло =)
Наверное еще страннее выйдет — http://www.smashingmagazine.com/2010/07/01/10-useful-wordpress-security-tweaks/
Ну я так и подумал что из одного источника откуда-то =)
Только дошел до 2 шага про SSL и сразу затык.
Хостер поддерживает. Включил в админке эту функцию. Вставил строку в wp-config и нате... При попытке зайти в админку блога ошибка (т.е. страница входа даже не загружается).
Безопасное подключение: критическая ошибка (552)
Opera не смогла подключиться к серверу. Вероятно, сервер использует неподдерживаемый протокол SSL 2, который не может считаться достаточно надёжным для безопасного соединения.
Владельцу сайта необходимо обновить протокол до TLS 1.0 или более нового.
Все понятно. Это вам надо с сервером воевать, если у вас не выделенный сервер, то опишите проблему хостеру, они разберутся.
У меня свой сервер, так тоже пришлось повозиться с тем, чтобы сперва для пользователя (пользователь сервера под которым работает сайт), а потом и для домена в настройках активировать SSL и выставить порт (по умолчанию 443 порт). Скорее всего что-то из этого не было выполнено.
Вы как разберетесь обязательно отпишитесь тут, мне важно знать в чем была проблема.
А я наверно просто откажусь от этой идеи с SSL...
Сейчас изучил FAQ хостера и нашел что для того, чтобы подключить SSL нужно подключить услугу выделенный IP, за которую придется доплачивать еще 100 р./мес. Ну и все сайты будут на одном IP соответственно, а я этого не хочу.
Понятно все. У меня гораздо проще, у меня выделенный сервер 4 ip в базовом комплекте да и что угодно могу сам себе подключить. Хотя наверное и цена аренды не сопоставима с вашей ;)
Спасибо. Вот только как добавить
RewriteEngine On
#Replace ?myblog\.ru/ with your blog url
RewriteCond %{HTTP_REFERER} !^http://(.+\.)?myblog\.ru/ [NC]
RewriteCond %{HTTP_REFERER} !^$
#Replace /images/nohotlink.jpg with your "don't hotlink" image url
RewriteRule .*\.(jpe?g|gif|bmp|png)$ /images/nohotlink.jpg [L]
к тому коду который уже есть в .htaccess
Хоть убей, ну не получается. Там уже стоит код wordpressa? как с ним интегрировать защиту от картинок. Буду рад ответу.
Все очень просто. Берете и добавляете данный код в начало файла .htaccess в корневой директории, куда установлен WP.
И не забудьте изменить данные на адрес вашего блога там, где это помечено.
В начале у меня
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^$ и тд...
Кула вставлять, подскажите. И извините за назойливость
Ну так в чем же проблема опять ;) Перед строчкой "# BEGIN WordPress" и вставьте. В самое самое начало файла.
Вставил, ничего не изменилось. Как стояли на других сайтов картинки с моей базы mysql так и стоят
Сейчас я работаю над этим, выясняю все причины по которым мог быть сбой. Скоро мы найдем разгадку к этому вопросу. Следите за комментариями, я обязательно опубликую тут решение.
Итак, проблема найдена. Все дело в том, что у вас наверняка стоит nginx на сервере. А соответственно он отдает картинки и правила (RewriteRule) работать не будут. Настройка там совсем другая, нежели чем для Апача, потому придется либо отказаться от идеи защиты от Хотлинка, либо просить хостеров настроить вам nginx на защиту от хотлинка, либо воспользоваться следующим плагином http://wordpress.org/extend/plugins/wordpress-automatic-image-hotlink-protection/
Вот такие вот дела.
Спасибо за старания я уже пробовал этот плагин раньше, да и сейчас попробовал, но нет придется с хостерами разговаривать.
Сколько мы не бились, но никак не получилось сделать чтобы вместо картинки отображалась заглушка (картинка подмена). То пустота отображается, то вообще не отображается. В общем как то не сложилась дружба у nginx с нашей хитростью. Вы если добьетесь необходимых результатов, обязательно отпишитесь мне.
Спасибо за статью.
4. Черный список нежеланных пользователей и ботов
А вот с этим нужно быть очень осторожным. Учитывая, что у большинства провайдеров IP-адреса — динамические, абсолютно реален шанс забанить не страшного и ужасного спамера, а обычного читателя. Я когда-то у себя столкнулся именно с такой проблемой.
Кроме того, если уж есть необходимость банить, то это можно делать не только по прямому IP, но и по части адреса. Например: deny from 124.15.
6. Боремся с парсерами и грабберами.
Граббить контент напрямую со страниц — это прошлый век, гораздо удобнее и оперативнее тырить его через RSS ;)
10. Предотвращаем прямой просмотр директорий
Промотр директорий также можно запретить, просто положив в корень пустой файл index.html (или index.php). В WordPress подобныt файлы уже размещены, но это не относится к пользовательским папкам.
З.Ы. В строке антиспама надо бы написать — цифрами или буквами вводить ответ. А то судя по длине поля — напрашивается "буквами".
проверил некоторые пункты у себя на одном блоге — часть из них заблокирована изначально уже провайдером ;) 10-ый например. А вообще статья полезная — в закладках )
Скорее всего не провайдером а хостером ;) И хорошо, грамотные админы всегда это сразу предусматривают.
Вау! Подписан на несколько блогов про WordPress, но нигде ещё такой инфы не видел. Попробую реализовать. Как раз бессонница. Хотелось бы еще обзор плагинов для безопасности . Хотя может у вас уже и есть пороюсь в архиве.
Нет, такого материала нет. Я предпочитаю использовать как можно меньше плагинов. Потому у меня обзоры, разработки и т.д. только хаков-трюков и все.
Я это уже понял. Только вот вопросик. Когда напильником движок правишь. После автоматического обновления хаки сохраняются?
Ну во-первых, я бы не рекомендовал автоматом обновляться. Ручками надежнее, точно знаешь, что ты делаешь и как. во-вторых на счет .htaccess я не уверен, но лучше перед обновлением сделать его копию, а вот если изменения касаются файла functions.php темы, то они останутся.
АлаичЪ, перевод конечно замечательный. Не знаю я делал ли ты эти рекомендации на своем блоге, судя по всему не все. Но в пункт по удалению версии WP надо внести одно существенное дополнение, а то даже если ты запретишь её вывод так как там написано, я и так смогу сказать, что ты давненько не обновлялся.
Способ настолько элементарен, что догадаться не так и просто. Оставлю шанс догадаться тебе самому, я и так слишком много подсказал. )))
Полезное шаманство. Ретвит
Есть, кстати, плагин какой-то, который во все папки пустой index.html добавляет.
Можно в настройках сервера запретить показывать файлы в папке если нет файла индекс. У нормальных хостеров это по умолчанию включено)
Спасибо очень полезная информация, для меня самым полезным является пункт №6.
пункт номер 6
Представте, что будет получать гугловый и яндексовый бот для поиска по картинкам
Представляю ;) Но ведь никто не запрещает создать исключение для роботов, собирающих картинки.
Статья как раз то что нужно. Я как раз собираю информацию по WordPress так как новичек в этом.
Спасибо автору за полезную информацию... Кое-что возьму себе на вооружение, поскольку у меня несколько сайтов на ВордПрессе...
У меня версия WordPress 3.4.2. Однако, в админке написано "имя пользователя изменить нельзя".
Значит выполните запрос в БД через phpmyadmin, как описано в посте.
Ув. АлаичЪ, какой из данных методов защиты вы используете на своем блоге? Или может какие-нибудь еще дополнительные?
Можно использовать хоть все трюки одновременно. Дополнить данный список нечем :)
Ну вот... находится нужная и полезная информация, когда её даже не ищешь. Ещё пару месяцев назад я искала инфу по 4, 6 и 8 пункту Вашей публикации и мало чего нашла. Но, как говорится лучше поздно, чем никогда.
Спасибо за подробный мануал. Побольше бы таких блогов.
А сегодня в 3.5.1 это еще актуально? Хорошо DLE-шникам, там расписано что в какой версии и как, а тут так, мимоходом :)
Не знаю, я не обновляюсь :)