10 полезных твиков для безопасности WordPress

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

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

Желаю вам удачи, и пусть ваши проекты не подвергаются взломам и прочим невзгодам.

С уважением, Александр Алаев
 
Ерунда и баянЪ!Зачет! Плюсую!
+13
 
Оптимизация сайта

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

от 10 000 руб.
Продвижение сайта

Комплексный подход к решению поставленных задач, будь то достижение заветных позиций в ТОП 10 или увеличение трафика на сайт. В стоимость уже включены полный технический аудит и оптимизация сайта.

от 15 000 руб.
Консультация

У вас недостаточно знаний?
Нужен ответ на ряд вопросов?
Хотите узнать мнение эксперта?
Вы задаете вопрос — я на него отвечаю!

1 500 руб./час
 
Получай новости блога АлаичЪ'а на e-mail:
 
Другие посты из категории WordPress:
Что нового на форуме:
  1. Shihal (1 комм.)

    Реально хороший и полезный пост. Честно говоря, подчерпнул для себя много нового в плане работы с htaccess. Сейчас сделаю ретвит, пусть другие тоже защищаются.

    Ответить
  2. МедиаМапа (2 комм.)

    Реально толковая статья. Как раз в тему. Сделал новый блог и думал о защите, а тут статья — спасибо Алычу. Делаю ретвит.

    Ответить
  3. bosha (6 комм.)

    Кажется на хабре была недавно такая же статья...

    Ответить
    • АлаичЪ

      Тебе всего лишь кажется =)

      Ответить
      • bosha (6 комм.)

        Если честно, то не похоже — http://habrahabr.ru/blogs/wordpress/98083/

        Я не упрекаю кого-то, просто странно вышло =)

        Ответить
        • АлаичЪ

          Наверное еще страннее выйдет — http://www.smashingmagazine.com/2010/07/01/10-useful-wordpress-security-tweaks/

          Ответить
          • bosha (6 комм.)

            Ну я так и подумал что из одного источника откуда-то =)

            Ответить
  4. RC-Master (2 комм.)

    Только дошел до 2 шага про SSL и сразу затык.

    Хостер поддерживает. Включил в админке эту функцию. Вставил строку в wp-config и нате... При попытке зайти в админку блога ошибка (т.е. страница входа даже не загружается).

    Безопасное подключение: критическая ошибка (552)

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

    Владельцу сайта необходимо обновить протокол до TLS 1.0 или более нового.

    Ответить
    • АлаичЪ

      Все понятно. Это вам надо с сервером воевать, если у вас не выделенный сервер, то опишите проблему хостеру, они разберутся.

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

      Вы как разберетесь обязательно отпишитесь тут, мне важно знать в чем была проблема.

      Ответить
      • RC-Master (2 комм.)

        А я наверно просто откажусь от этой идеи с SSL...

        Сейчас изучил FAQ хостера и нашел что для того, чтобы подключить SSL нужно подключить услугу выделенный IP, за которую придется доплачивать еще 100 р./мес. Ну и все сайты будут на одном IP соответственно, а я этого не хочу.

        Ответить
        • АлаичЪ

          Понятно все. У меня гораздо проще, у меня выделенный сервер 4 ip в базовом комплекте да и что угодно могу сам себе подключить. Хотя наверное и цена аренды не сопоставима с вашей ;)

          Ответить
  5. Gardarik (5 комм.)

    Спасибо. Вот только как добавить

    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.

      И не забудьте изменить данные на адрес вашего блога там, где это помечено.

      Ответить
  6. Gardarik (5 комм.)

    В начале у меня

    # BEGIN WordPress

    <IfModule mod_rewrite.c>

    RewriteEngine On

    RewriteCond %{HTTP_REFERER} !^$ и тд...

    Кула вставлять, подскажите. И извините за назойливость

    Ответить
    • АлаичЪ

      Ну так в чем же проблема опять ;) Перед строчкой "# BEGIN WordPress" и вставьте. В самое самое начало файла.

      Ответить
  7. Gardarik (5 комм.)

    Вставил, ничего не изменилось. Как стояли на других сайтов картинки с моей базы mysql так и стоят

    Ответить
    • АлаичЪ

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

      Ответить
    • АлаичЪ

      Итак, проблема найдена. Все дело в том, что у вас наверняка стоит nginx на сервере. А соответственно он отдает картинки и правила (RewriteRule) работать не будут. Настройка там совсем другая, нежели чем для Апача, потому придется либо отказаться от идеи защиты от Хотлинка, либо просить хостеров настроить вам nginx на защиту от хотлинка, либо воспользоваться следующим плагином http://wordpress.org/extend/plugins/wordpress-automatic-image-hotlink-protection/

      Вот такие вот дела.

      Ответить
      • Gardarik (5 комм.)

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

        Ответить
        • АлаичЪ

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

          Ответить
  8. Yaroslav.CH (9 комм.)

    Спасибо за статью.

    4. Черный список нежеланных пользователей и ботов

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

    Кроме того, если уж есть необходимость банить, то это можно делать не только по прямому IP, но и по части адреса. Например: deny from 124.15.

    6. Боремся с парсерами и грабберами.

    Граббить контент напрямую со страниц — это прошлый век, гораздо удобнее и оперативнее тырить его через RSS ;)

    10. Предотвращаем прямой просмотр директорий

    Промотр директорий также можно запретить, просто положив в корень пустой файл index.html (или index.php). В WordPress подобныt файлы уже размещены, но это не относится к пользовательским папкам.

    З.Ы. В строке антиспама надо бы написать — цифрами или буквами вводить ответ. А то судя по длине поля — напрашивается "буквами".

    Ответить
  9. Денис (6 комм.)

    проверил некоторые пункты у себя на одном блоге — часть из них заблокирована изначально уже провайдером ;) 10-ый например. А вообще статья полезная — в закладках )

    Ответить
    • АлаичЪ

      Скорее всего не провайдером а хостером ;) И хорошо, грамотные админы всегда это сразу предусматривают.

      Ответить
  10. Павел (4 комм.)

    Вау! Подписан на несколько блогов про WordPress, но нигде ещё такой инфы не видел. Попробую реализовать. Как раз бессонница. Хотелось бы еще обзор плагинов для безопасности . Хотя может у вас уже и есть пороюсь в архиве.

    Ответить
    • АлаичЪ

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

      Ответить
      • Павел (4 комм.)

        Я это уже понял. Только вот вопросик. Когда напильником движок правишь. После автоматического обновления хаки сохраняются?

        Ответить
        • АлаичЪ

          Ну во-первых, я бы не рекомендовал автоматом обновляться. Ручками надежнее, точно знаешь, что ты делаешь и как. во-вторых на счет .htaccess я не уверен, но лучше перед обновлением сделать его копию, а вот если изменения касаются файла functions.php темы, то они останутся.

          Ответить
  11. TiamatInc (93 комм.)

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

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

    Ответить
  12. Akceptor (1 комм.)

    Полезное шаманство. Ретвит

    Есть, кстати, плагин какой-то, который во все папки пустой index.html добавляет.

    Ответить
    • Сибирский парень (1 комм.)

      Можно в настройках сервера запретить показывать файлы в папке если нет файла индекс. У нормальных хостеров это по умолчанию включено)

      Ответить
  13. dizel (2 комм.)

    Спасибо очень полезная информация, для меня самым полезным является пункт №6.

    Ответить
  14. volos_86 (4 комм.)

    пункт номер 6

    Представте, что будет получать гугловый и яндексовый бот для поиска по картинкам

    Ответить
    • АлаичЪ

      Представляю ;) Но ведь никто не запрещает создать исключение для роботов, собирающих картинки.

      Ответить
  15. Вадик (2 комм.)

    Статья как раз то что нужно. Я как раз собираю информацию по WordPress так как новичек в этом.

    Ответить
  16. Roger232 (1 комм.)

    Спасибо автору за полезную информацию... Кое-что возьму себе на вооружение, поскольку у меня несколько сайтов на ВордПрессе...

    Ответить
  17. Dorian Grey (1 комм.)

    У меня версия WordPress 3.4.2. Однако, в админке написано "имя пользователя изменить нельзя".

    Ответить
    • АлаичЪ

      Значит выполните запрос в БД через phpmyadmin, как описано в посте.

      Ответить
  18. Данил (16 комм.)

    Ув. АлаичЪ, какой из данных методов защиты вы используете на своем блоге? Или может какие-нибудь еще дополнительные?

    Ответить
    • АлаичЪ

      Можно использовать хоть все трюки одновременно. Дополнить данный список нечем :)

      Ответить
  19. Oksana (1 комм.)

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

    Спасибо за подробный мануал. Побольше бы таких блогов.

    Ответить
  20. Valera (2 комм.)

    А сегодня в 3.5.1 это еще актуально? Хорошо DLE-шникам, там расписано что в какой версии и как, а тут так, мимоходом :)

    Ответить
Оставь комментарий или спроси через Twitter →

· Малоинформативные комментарии или комментарии, не содержащие вопрос, удаляются.
· В поле URL оставляйте ссылку только на свой сайт/блог. Эта ссылка для админа, посетители ее не увидят.
· Любой html-код отображается в виде текста, любые ссылки неактивны.
· Для спаммеров - БЛОГ НЕ DOFOLLOW!!!