Улучшаем безопасность сайта на WordPress

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

Безопасность WordPress!

1. Перед инсталляцией;
2. После инсталляции;
3. Периодические проверки и обновления.

1. Перед инсталляцией

1.1. Удаляем все ненужные файлы:
readme.html, license.txt, hello.php, ненужные темы и плагины.

1.2. Правильно отредактируем wp-config.php файл:

define('DB_NAME', 'wpdb'); // Вместо 'wpdb' нужно придумать сильное имя, например, wp433Fd6HW
define('DB_USER', 'wpuser'); // Например, UserFB56SKl
define('DB_PASSWORD', 'strongpassword'); // Тут должен быть сильный пароль, например, ‘FE876!8e#fh#9fDfds9f’
define('DB_HOST', 'localhost'); // В 99% случаях это значение не нужно менять
define('DB_CHARSET', 'utf8'); define('DB_COLLATE', '');

Меняем секретный ключ с дефолтного:

define('AUTH_KEY',        'izmenite eto na unikalnuyu frazu');
define('SECURE_AUTH_KEY', 'izmenite eto na unikalnuyu frazu');
define('LOGGED_IN_KEY',   'izmenite eto na unikalnuyu frazu');
define('NONCE_KEY',       'izmenite eto na unikalnuyu frazu');

на сгенерированный, с помощью сервиса http://api.wordpress.org/secret-key/1.1/

define('AUTH_KEY',        'M.uFL(R<FxXDJ8(TQ.V?YE}MB;XMTECTwxt6;7PD*=1_xlz^FL8;<>B[PX0IoKLR');
define('SECURE_AUTH_KEY', '/SD?GeMiI&?yb5l(Tb|pDLo=ZA^dkD;@GYlDB :dM=Ax$>9-DMI,0&AwT50`%f2s');
define('LOGGED_IN_KEY',   'yc,:[tN_cMmwP }wk]w5UkRw%P&+>E*jJZBikz3-OV7sO*-_g*{9z,PnM,T&LPAE');
define('NONCE_KEY',       'd2<?G|=9LRD$M]|B/f-<K$ RdAwCP4aAp,>A~8NBb%2?+6`z}?nWoD0`f]-.gUOC);

Делаем таблицы более защищенными:

$table_prefix = 'wp_4i32aK_'; // Используйте только буквы, числа и символы подчерка, чтобы сделать свой table_prefix уникальным. По крайней мере, это защитит Вас от части public эксплоитов.

1.3. Создаём пользователя и базу данных для блога в консоле MySQL:
Сначала, заходим под root’ом и создаем базу данных для блога:

$ mysql -u root
mysql> CREATE database wpdb;
Query OK, 1 row affected (0.00 sec)

В нашем примере это будет выглядеть так:

$ mysql -u root
mysql> CREATE database wp433Fd6HW;
Query OK, 1 row affected (0.00 sec)

Затем создаём пользователя: этот аккаунт будет иметь доступ только в базе данных WordPress. Также мы можем быть уверены, что пользователь используется только с локального сервера, а не удаленно.

mysql> GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP
-> ON wpdb.*
-> TO 'wpuser'@'localhost'
-> IDENTIFIED BY 'strongpassword'; Query OK, 0 rows affected (0.01 sec)

В нашем примере это будет выглядеть так:

mysql> GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP
-> ON wp433Fd6HW.*
-> TO 'UserFB56SKl'@'localhost'
-> IDENTIFIED BY 'FE876!8e#fh#9fDfds9f';
Query OK, 0 rows affected (0.01 sec)

1.4. Уберите блок meta из кода Вашей темы
В стандартной теме кусок кода, отвечающего за вывод блока meta:

<li><h2>Meta</h2>
<ul>
<?php wp_register(); ?>
<li><?php wp_loginout(); ?></li>
<li><a href="http://validator.w3.org/check/referer" title="This page validates as XHTML 1.0 Transitional">Valid <abbr title="eXtensible HyperText Markup Language">XHTML</abbr></a></li>
<li><a href="http://gmpg.org/xfn/"><abbr title="XHTML Friends Network">XFN</abbr></a></li>
<li><a href="http://mywordpress.ru/" title="<?php _e('Powered by WordPress, state-of-the-art semantic personal publishing platform.', 'kubrick'); ?>">WordPress</a></li>
<?php wp_meta(); ?>
</ul>
</li>

2. После инсталляции

2.1. Меняем пароль Администратора по умолчанию
Поменяйте сгенерированный на этапе установки пароль Администратора

2.2. Удаляем версию WordPress
В файле functions.php в папке с Вашей темой добавляем строку:

remove_action ('wp_head', 'wp_generator');

В файле header.php в папке с Вашей темой удаляем строку:

<meta name="generator" content="WordPress <?php bloginfo('version'); ?>" />

Для WordPress версии 2.8.4 находим имплементацию функции get_the_generator($type) и изменяем ее:

function get_the_generator( $type ) {
$gen = '<!-- -->';
return apply_filters( "get_the_generator_{$type}", $gen, $type );
}

2.3. Пустой index.php
Поместите в папки wp-includes/, wp-content/, /plugins/ пустой файл index.php

2.4. Меняем имя пользователя Admin на нечто более неочевидное
Изменяем имя через MySQL консоль:

wp $ mysql -u UserFB56SKl –p
mysql> use wp;
UPDATE wp_users SET user_login='adm' where user_login='admin';
Query OK, 1 row affected (0.01 sec) Rows matched: 1 Changed: 1 Warnings: 0

В нашем примере это будет выглядеть так:

wp $ mysql -u wpuser –p
mysql> use wp433Fd6HW;
UPDATE wp_4i32aK_users SET user_login='adm234Df' where user_login='admin';
Query OK, 1 row affected (0.01 sec) Rows matched: 1 Changed: 1 Warnings: 0

Или, если не хотите копаться с запросами, можно сделать следующее:

1. Cоздайте новый аккаунт. Имя пользователя должно быть уникальным;
2. Назначьте новому пользователю роль Администратора;
3. Перелогинтесть как новый Администратор;
4. Удалите учетку старого Администратора.

2.5. Создаём новые роли пользователей
Для этого необходимо сначала установить на Ваш блог плагин Role Manager. Этот плагин даст Вам возможность скрупулезно и точечно устанавливать права пользователей. После активации плагина Вам, для начала нужно создать пользователя для себя. Удалите все права пользователя и затем внимательно выберите только те права, которые понадобятся Вам для ежедневной активности (писать посты, модерировать комментарии и тд). Удостоверьтесь, что только админский аккаунт имеет привилегии для активации / дезактивации плагинов, загрузки файлов, управлении опциями, переключении тем, импорт и тд.
Если в Вашем блог будет многопользовательским, то необходимо подумать о том, какие права действительно нужны пользователям и создать на основе этого свои собственные роли.
При создании ролей будьте осторожны, раздавая пользователям такие права как: аплоад файлов, доступ к редактированию исходного кода плагинов, активации плагинов, редактировании файлов / постов / страниц, импорт, нефильтрованный HTML, так как эти роли дают пользователям большие полномочия.

2.6. Ограничиваем доступ к папкам wp-content и wp-includes
С помощь файла .htaccess и специальных правил, мы запретим всё, кроме запросов на картинки, CSS и JavaScript. Файлы .htaccess необходимо положить с соответствующие директории.

Order Allow, Deny
Deny from all
<Files ~”.(css|jpe?g|png|gif|js)$”>
Allow from all
</Files>

Вы также можете добавить специфические PHP файлы для определенных шаблонов и плагинов.

2.7. Прячем директорию wp-content
Начиная с версии WordPress 2.6, появилась возможность переместить директорию wp-content.
Меняем в wp-settings.php строчки:

define('WP_CONTENT_DIR',$_SERVER['DOCUMENT_ROOT'].'/blog/wp-content');
define('WP_CONTENT_URL','http://domain.ru/blog/wp-content');

И, чтобы не было проблем с плагинами:

define('WP_PLUGIN_DIR',$_SERVER['DOCUMENT_ROOT'].'/blog/wp-content/plugins');
define('WP_PLUGIN_URL','http://domain.ru/blog/wp-conten/plugins');

2.8. Ограничиваем доступ к папке wp-admin
Если у Вас статический IP
Этот шаг легко осуществим для однопользовательского блога, но может принести настоящую головную боль для многопользовательского варианта. Этот трюк подходит только, если у Вас статический IP. Файл .htaccess для директории wp-admin должен содержать следующие правила:

AuthUserFile /dev/null
AuthGroupFile /dev/null
AuthName "Example Access Control"
AuthType Basic
<LIMIT GET>
order deny,allow
deny from all
allow from a.b.c.d. #Ваш статический IP
</LIMIT>

Положите файл в директорию wp-admin и попробуйте зайти в эту папку через прокси. Если всё работает правильно, в доступе будет отказано. После этого попробуйте зайти со своего IP.

Ограничиваем доступ по паролю
Более предпочтительным может оказаться доступ к папке wp-admin по паролю. А это означает, что Вы можете заходить в админскую панель, откуда угодно. Также это вариант, если у Вас динамический IP.
Файл .htaccess для директории wp-admin должен содержать следующие правила:

#Файл .htpasswd находиться за пределами root директории Вашего блога

ErrorDocument 401 default
AuthUserFile /srv/www/user1/.htpasswd
AuthType Basic
AuthName "WordPress Dashboard"
<Files "wp-login.php">
require user adminuser #Создайте секъюрный username
</Files>
<Files "xmlrpc.php">
require valid-user
</Files>

Сгенерируйте пароль командой:

$ htpasswd -cm .htpasswd adminuser

Или для генерации пароля воспользуйтесь сервисом http://www.htaccesstools.com/htaccess-authentication/ . Вот пример для user: admin , password: test

admin:$apr1$t3qLL...$uUmj9Wm/WbJk7YNza6ncM/

Файл .htpasswd лучше расположить директорией выше корня блога.

2.9. Файл wp-config.php
Вариант первый: для защиты Ваших данных необходимо перебросить на папку выше, WordPress автоматически проверит директорию выше если не найдет у себя в корне wp-config.php.
Если по каким-то причинам Вы не можете проделать того, что описано выше, то существует еще один вариант. А именно – защитить Ваш wp-config.php с помощью .htaccess :

# protect wpconfig.php
<files wp-config.php>
Order deny,allow
deny from all
</files>

2.10. Устанавливаем правильные права на файлы и папки
Основное правило:

1. Для файлов - 644
2. Для папок - 755

Из шелла эти операции можно проделать с помощью:

cd <wp-root-folder>
find (your path) -type d -exec chmod 755 ‘{}’ \
find (your path) -type f -exec chmod 644 ‘{}’ \

2.11. SSL для админов
Если Ваш сервер поддерживает SSL, то лучше сделать доступ в админку защищенной. Для этого в файле wp-config.php уберите комментарии в строчке:

define(’FORCE_SSL_ADMIN’, true);

2.12. Удалите вывод логов WordPress
В файле functions.php в папке с Вашей темой добавляем строку:

add_filter('login_errors',create_function('$a', "return null;"));

2.13. Запрещаем индексации с помощью Robots.txt
Проверить правильность можно по адресу http://www.yandex.ru/cgi-bin/test-robots

2.14. Плагины для Вашей безопасности
Login LockDown - Устанавливаем количество ложных логинов
Для этого есть два решения в виде плагинов Login LockDown and Limit Login Attempts. После того, как плагин активирован, он записывает все попытки залогиниться. Плагин позволяет запретить посетителю логиниться определенное время, после того как посетитель несколько раз неправильно ввёл пароль.

Belavir – Следим за изменениями в ключевых php файлах
http://blog.portal.kharkov.ua/2008/06/27/belavir/

WPIDS – Определяем признаки внедрения
http://blogsecurity.net/wordpress/wpids-wordpress-intruder-detection-system

WordPress Online Security Scanner – Сканируем блог на уязвимости
http://blogsecurity.net/wordpress/news-140707/

Akismit – Противоборство СПИДу СПАМу
http://akismet.com/

SpamBam – Определяем валидный ли браузер пользует клиент
http://blogsecurity.net/wordpress/spambam-comment-anti-spam-plugin

3. Периодические проверки и обновления

3.1. Следите за обновлением WordPress
3.2. Следите за обновлением плагинов
3.3. Следите за обновлениями безопасности
http://secunia.com/advisories/search/?search=WordPress
3.4. Проверяйте код темы и плагинов, которые Вы хотите добавить, на «дырявость»
3.5. Боритесь со спамом
3.6. Регулярно делайте полный backup базы данных Вашего блога
3.7. Читайте девелоперские блоги
Небольшой список:

1. http://lorelle.wordpress.com
2. http://blogsecurity.net
3. http://wordpress.org/development/

Также можете прочитать неплохой Guide на англ. яз. - http://www.nercomp.org/data/media/WordPress%20Security-Rode.pdf

Рубрика: Настройка WordPress | 29 сентября 2009

Предыдущие записи из рубрики `Настройка WordPress`

24 комментария

Ветер, 24.08.2013 в 16:32

Deimos, естественный вопрос: следует ли производить после таких изменений обновления моторчика(двигателя) WP?

А по поводу пустых index.php, то к ним, после опустошения структуры, можно подключать стеки, сейчас это новая фича хачей, ссылку можете удалить потому не поделюсь, вообщем на официальном форуме WP есть топик о взломах how to connect stack on index file, да и не только.

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

За Ваш труд, Спасибо! Держу на складе брайзера.

ОтветитьОтветить
Ветер, 25.08.2013 в 00:29

Версию движка всё равно узнал, как ни пытался её скрыть, а выдаёт её следующий скрипт:

параграф 1.2, в нём первый и четвёртый примерные блоки лучше не приводить к действию, иначе сайт блокируется сообщением Error 404 или соответствующим текстовым сообщением, тестировал на реальном хосте и на локалке.

Папка js в WordPress хоть там и немного сабжа(объектов), но это сильно делает уязвимым блог и движёк: узнать версию движка, подключить скрипты и удить инфу - как конфетку у ребёнка.

uCoz так себе(но туда я ни ногой), а WP очень разочаровал - дырявый как и Битрикс(хотя этот вообще).

Со всем разобрался. Спасибо!

ОтветитьОтветить
Sonia, 02.10.2013 в 12:17

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

ОтветитьОтветить
kama, 05.12.2013 в 08:03

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

ОтветитьОтветить

Комментировать

Новые комментарии