Безопасность и защита WordPress - как защититься

защита wordpress, безопасность wordpress

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

В этой статье описаны уловки, которые позволят сделать ваш сайт на WordPress’e ещё более защищённым. Помните: перед любыми изменениями лучше на всякий случай сделать резервные копии сайта.

Установка обновлений

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

Также рекомендуется включить автоматическое обновление, в файле wp-config.php пропишите:

define('WP_AUTO_UPDATE_CORE', true);

Это включит автоматическое обновление wordpress как для минорных (второстепенных), так и для мажорных (главных) версий wordpress.

Это же, можно включить через прописывание кода в файле functions.php (но лучше в свой плагин):

  • add_filter( 'auto_update_core', '__return_true' ); - включаем минорные и мажорные обновления WordPress
  • add_filter( 'allow_minor_auto_core_updates', '__return_true' );  - только минорные
  • add_filter( 'allow_major_auto_core_updates', '__return_true' );  - только мажорные
  • add_filter( 'auto_update_plugin', '__return_true' ); - автоматическое обновление всех плагинов
  • add_filter( 'auto_update_theme', '__return_true' ); - автоматическое обновление всех тем, используйте с аккуратностью, так как темы часто дорабатываются и редактируются, то ее обновление может стереть ваши доработки.

Удаление неиспользуемых плагинов и шаблонов

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

Регулярное резервное копирование

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

Смена префикса базы данных

Поменяется стандартный префикс базы данных со стандартного wp_ на что-либо другое. Делается это для того, чтобы в случае возможности SQL-инъекции усложнить анализ таблиц вашей базы данных. Сделать это можно руками, не забыв поправить файл wp-config.php или же при помощи плагина Change DB Prefix.

Если руками, то в файле wp-config.php ищите строку:

$table_prefix  = 'wp_';

Скрываем версию WordPress'a

Этот пункт довольно спорный, так как профессионалы могут определить версию wordpress по множеству факторов: если вкратце, то версию wordpress можно узнать не только по meta name=”generator” в исходном тексте страницы, но и по файлу readme.html в корне сайта, rss/atom генератору, версиям css файлов на странице wp-login.php и файлов в папке /wp-includes/js/.

Процесс скрытия версии WordPress более подробно описан в статье "Как узнать версию WordPress и скрыть версию WordPress".

Использование SSL для входа в админку

Если у вас есть возможность использовать SSL, то открываем файл wp-config.php (обитающий в корне сайта) и добавляем следующую строку:

define('FORCE_SSL_ADMIN', true);

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

Защита wordpress от хотлинкинга

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

В файле .htaccess пишем следующее:

RewriteEngine On
#Замените ?mysite\.ru/ на адрес вашего сайта
RewriteCond %{HTTP_REFERER} !^http://(.+\.)?mysite\.ru/ [NC]
RewriteCond %{HTTP_REFERER} !^$
#Замените /images/nohotlink.jpg на название вашей картинки
RewriteRule .*\.(jpe?g|gif|bmp|png)$ /images/nohotlink.jpg [L]

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

Защита wordpress от iFrame

Контент вашего сайта могут отображать во frame-окнах, что создает лишнюю нагрузку на сервер и по сути является воровством производительных ресурсов. Как защититься от этого я писал в записи Запрет просмотра сайта через iframe.

Защита файлов wp-admin и wp-login

В wordpress для доступа к админ панели используются стандартные адреса: site.com/wp-admin/ и site.com/wp-login.php. При помощи плагинов можно переименовать. Тогда злоумышленники не будут знать по какому адресу посылать запросы на получения доступа к админ панели.

Также wp-login можно защитить следующим образом:

  • Копируем файл wp-login.php например под именем super-login.php
  • В файле super-login.php заменяем все вхождения текста "wp-login.php" на " super-login.php"
  • Блокируем доступ к wp-login.php через htaccess:
<Files wp-login.php>
 Order Allow,Deny
 Deny from all
</Files>
  • Блокируем POST запросы к wp-login.php через htaccess:
#Запрет POST запросов к wp-login.php
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} ^/wp-login\.php$
RewriteRule .? - [F]

Теперь для входа в админку используйте адрес "example.com/super-login.php"

Есть и другие варианты защиты wp-login.php, их можно прочесть вот тут: codex.wordpress.org/Brute_Force_Attacks

Ограничиваем доступ к файлам

Расставляем права доступа в ftp

  • Директории — 755 или 750
  • файлы — 644 или 640
  • wp-config.php — 600.

Защищаем wp-config и xmlrpc через .htaccess

wp-config.php содержит все данные, необходимые для подключения к серверу MySQL и базе данных. Защита этого файла – важная задача.

файл xmlrpc.php часто используется в разных атаках, к нему также рекомендуется закрыть доступ.

В файле .htaccess прописываем :

Options -Indexes
<files ~ "(wp-config|xmlrpc).php$">
order allow,deny
deny from all
</files> 

Защищаем папку wp-includes

В папке /wp-includes/ создаем .htaccess вот с таким содержимым:

order deny,allow
deny from all
<files ~ "(.(xml|css|jp?g|png|gif|js)|wp-tinymce.php)$">
 allow from all
</files>

Тем самым закрывая извне доступ ко всему, кроме перечисленных выше типов файлов .

Защита директорий на сервере от просмотра

Очень многие хостеры позволяют просматривать директории на своих серверах. Поэтому, если например ввести в адресную строку www.вашблог.ru/wp-includes, то очень часто можно увидеть всё содержимое этой директории. Безусловно это небезопасно, поэтому лучше это сразу запретить.

Вы можете либо добавить пустые файлы index.html в папки, просмотр которых хотели бы запретить. Либо дополнить наш .htaccess ещё одной строкой:

Options All -Indexes

Пустой index.html будет выдаваться каждый раз, когда последует запрос к директории. Ну а директива в .htaccess просто запрещает апачу выдавать список содержимого директории.

Защищаемся от спамеров и ботов

Если Вам надоел какой-то спамер, то решение – запретить ему доступ к сайту по IP. Это конечно не защитит от спам-скриптов, меняющих прокси, но иногда может пригодится. Вставьте этот код в файл .htaccess. Просто поменяйте адрес 123.456.789 на IP нехорошего человека, который вас достаёт и всё — он забанен:

<Limit GET POST PUT>
order allow,deny
allow from all
deny from 123.456.789
</LIMIT>

Так мы запрещаем доступ к сайту пользователям с конкретным IP. Нужно забанить ещё кого-то? Просто добавим ещё одну строку, к примеру —

deny from 93.121.78.8

Можно защититься от спамеров и ботов более хитрым способом: они часто не используют заголовки HTTP_REFERER и HTTP_USER_AGENT, в отличии от обычных браузеров, а значит можно запретить все POST запросы где в HTTP_REFERER не указан ваш сайт или же нет HTTP_USER_AGENT, пишем код в файл htaccess:

# Stop spam attack logins and comments
<IfModule mod_rewrite.c>
	RewriteEngine On
	RewriteCond %{REQUEST_METHOD} POST
	RewriteCond %{REQUEST_URI} .(wp-comments-post|wp-login)\.php*
	RewriteCond %{HTTP_REFERER} !.*example.com.* [OR]
	RewriteCond %{HTTP_USER_AGENT} ^$
	RewriteRule (.*) - [F,L]
</ifModule>

Также в защите от вредоносных запросов, спама, плогих агентов поможет так называемый htaccess-фаервол - набор правил для htaccess 6G Firewall 2016

Использование устойчивых паролей

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

Пароли должны быть длиной от 8-ми символов и одновременно состоять из маленьких букв, больших букв, цифр и не алфавитных знаков (!,@,#,$ и т.д.). Как же запоминать такие пароли? Пользуйтесь сервисами которые автоматически генерируют, сохраняют, заполняют пароли. О самом известном сервисе такого рода я писал в статье LastPass - храните пароли не в голове а на сервере

Не показываем сообщение о неверном пароле

Если при попытке зайти в админку WordPress’a вы ошибётесь с логином или паролем, вежливый движок скажет вам об этом. Зачем злоумышленнику знать, что пароль, который он пытается подобрать – неверен? Можно убрать вывод этой информации и чуть запутать его.

В файл functions.php добавляем строчку:

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

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

Защита wordpress от подбора пароля

Опишу два метода защиты (помимо тех, которые описаны выше):

  • Установить один из плагинов блокирующий ip с которого происходят попытки ввода неправильных паролей, например плагин Limit Login Attempts.
  • Если вы входите в wordpress только с определенных компьютеров то в .htaccess можно заблокировать доступ к админке со всех ip адресов кроме ваших. Можно указывать сети, если адрес вашего провайдера динамический:
#Защита wordpress сайта от подбора пароля
<Files wp-login.php>
Order Deny,Allow
Deny from all
allow from 33.43.36.73
allow from 21.27.15.0/24
</Files>

Переименование учетки "admin"

Злоумышленникам всегда проще получить доступ к сайту при помощи подбора пароля, если уже известен логин. При этом на протяжении многих лет логин админа по умолчанию был примитивным — «admin».

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

UPDATE wp_users SET user_login = 'Ваш новый логин' WHERE user_login = 'Admin';

С помощью sql-запроса меняем дефолтный логин. Правда, есть одно «но». Посты, написанные ранее admin'ом не поменяют своего автора. А для того чтобы извести admin'a на корню, необходимо выполнить ещё один запрос:

UPDATE wp_posts SET post_author = 'Ваш новый логин' WHERE post_author = 'admin';

Скрытие имени пользователя

WordPress может где-либо выводить username пользователя который опубликовал запись. Например в шаблоне могут выводиться ссылки на архивы автора: elims.org.ua/author/admin/ Благодаря этому злоумышленники будут знать к какому login'у учетки можно подбирать пароль. Позаботьтесь о том, чтобы этого не было.

Мало того, в базе данных в таблице wp_users в поле user_nicename можно установить имя, которое будет отличаться от логина user_login. Значение поля user_nicename как раз и используется для генерации ссылки на архив автора. Таким образом даже если злоумышленникам и получиться найти ссылку на архив автора, то она не выдаст ваш login.

Защищаем WordPress от XSS-инъекций

Программисты обычно стараются защитить GET- и POST- запросы, однако, иногда этого недостаточно. Необходимо защитить блог от XSS-инъекций и попыток модификации переменных GLOBALS и _REQUEST.

Следующий код блокирует использование XSS-инъекций и попытки модифицировать переменные GLOBALS и_REQUEST. Вставьте код в файл .htacces

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]

Код блокирует 403-й ошибкой запросы которые содержат тег <script> или попытку модифицировать значение переменных GLOBALS и _REQUEST.

Пишем плагин для защиты от зловредных url-запросов

Хакеры часто пытаются найти слабые места при помощи всевозможных зловредных запросов. WordPress неплохо защищён от этого, но лишняя защита никогда не повредит.

Создаём новый файл под названием blockbadqueries.php и помещаем его в папку wp-content/plugins. Затем просто активируйте его в админке как любой другой плагин.

<?php
/*
Plugin Name: Block Bad Queries
Plugin URI: perishablepress.com/press/2009/12/22/protect-wordpress-against-malicious-url-requests
Description: Protect WordPress Against Malicious URL Requests
Author URI: 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 символов) и наличие php-функций eval или base64 в URI. Если что-то из этого находится, браузеру пользователя отдаётся страница с ошибкой 414.

Отключение XML-RPC Pingback

В начале 2014-го года по интернету пронеслась новость о том, что в DDoS-атаке использовалось более 162 000 ничего не подозревающих wordpress сайтов. Суть атаки сводиться к тому, что злоумышленник выдавая себя за атакуемый сайт присылает pingback запросы на блоги, которые используются в DDoS-атаке.

Запросы выглядят так:

91.178.92.78 - - [08/Mar/2014:21:13:36 -0400] "POST /xmlrpc.php HTTP/1.0" 403 4034 "-" "-" "POSTREQUEST:<?xml version=\x221.0\x22 encoding=\x22iso-8859-1\x22?>\x0A<methodCall>\x0A<methodName>pingback.ping</methodName>\x0A<params>\x0A <param>\x0A <value>\x0A <string>http://attackedsite.com/?1698491=8940641</string>\x0A </value>\x0A </param>\x0A <param>\x0A <value>\x0A <string>yoursite.com</string>\x0A </value>\x0A </param>\x0A</params>\x0A</methodCall>\x0A"

Чтобы Ваш сайт не использовался в подобных атаках необходимо отключить функционал XML-RPC Pingback. Можно добавить код в файл functions.php или создать плагин с следующим кодом:

add_filter( ‘xmlrpc_methods’, function( $methods ) {
 unset( $methods['pingback.ping'] );
 return $methods;
 } );

Но я пошел более кардинальным путем: просто заблокировал доступ к файлу xmlrpc.php. Для этого нужно добавить в файл .htaccess следующий код:

# protect xmlrpc
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>

Источник: habr.ru/post/98083

Журналы событий

Установите плагины которые ведут различные журналы событий на вашем сайте. Журналы могут быть самые разные: удачные и неудачные попытки входа, изменение плагинов, шаблонов, настроек сайта, изменение файлов сайта и тд. и тп. Есть плагины которые умеют за всем этим следить. Также поинтересуйтесь какие журналы ведет ваш хостинг - в большинстве случаев хостинг предоставляет журнал веб-сервера благодаря которому можно посмотреть кто какие страницы посещал и выявить атаку, например ерез 404-е и 403-и ошибки, еще на том этапе, когда она не принесла вреда.

Защищенный хостинг

Если защита wordpess сайта идеальна, но при этом доступ к хостингу не защищен, то все вышеописанное - пустая трата времени. Отключите доступ к FTP, активируйте двухфакторную авторизацию  (пароль приходит в sms на телефон) к хостингу. Если он это поддерживает. Мой хостинг кстати это поддерживает, читайте обзор хостинга Ukraine.

Отключение установки, обновления, редактирования тем и плагинов

Если злоумышленнику таки удалось попасть к вам в админ панель, то дополнительной "палкой в колеса" будет отключение возможности редактировать шаблоны из админ панели через редактор тем. Прописываем в файле wp-config.php строку:

 definedefine( ‘DISALLOW_FILE_EDIT’, true );

Также можно отключить обновление и установку плагинов из админки:

 define( 'DISALLOW_FILE_MODS',true);

Запрет на изменение файлов хостинга

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

To perform the requested action, WordPress needs to access your web server. Please enter your FTP credentials to proceed. If you do not remember your credentials, you should contact your web host.

Таким образом если у кого-то и будет доступ к админке wordpress, то плагины и темы изменить он не сможет. Правда опубликовать что-либо или наоборот стереть получится.

Отключение вывода ошибок php

Если проверять свой wordpress сайт при помощи таких сканеров безопасности как wpsec.ru, то можно увидеть такое не критическое предупреждение

Full Path Disclosure rss-functions.php

Оно говорит о том, что если перейти по адресу site.org.ua/wp-includes/rss-functions.php то можно увидеть ошибку php в которой раскрывается полный путь к этому файлу на хостинге.  Благодаря этой информации можно попытаться использовать некоторые уязвимости, подробней можно прочесть на сайте owasp.org или hakipedia.com.

Чтобы отключить вывод ошибок php нужно сделать одно из двух действий, в зависимости от конфигурации вашего хостинга:

Прописать в файле .htaccess строку

php_flag display_errors off

если же это вызвало ошибку "internal server error", то удалить эту строку и отключить вывод ошибок в файле "php.ini" при помощи строки:

display_errors = 'off'

Я использую Хостинг Украина и у меня это отключается через настройки php для сайта: просто убирается галочка возле надписи "display_errors".

Также можно прописать вот этот код в файл wp-config:

error_reporting(0); @ini_set('display_errors', 0);

Плагины усиливающие безопасность WordPress

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

Полезные ссылки:

Понравилось? =) Поделись с друзьями:

Обсуждение записи “Безопасность и защита WordPress - как защититься”

  1. name nika (olgworld.com) says:

    Владимир, а прописывание в файле .htaccess доступ по своему ip-адресу принципиально ничего не решает?

  2. Владимир Демянович (elims.org.ua) says:

    name nika, защиту админки при помощи разрешения в .htaccess только своих ip-адресов и запрета всех других считаю наиболее надежной и наименее нагрузочной для хостинга.

  3. name nika (olgworld.com) says:

    Насчет запрета не уверена.У меня стоял плагин защиты iThemes Security.Там можно было в бан прописывать ip.У меня видимо попал Яндекс бот в черный список.Притом увидела не сразу. Блог начал выдавать ошибку 403 для Яндекса.Так что, с черным списком я остерегусь.

  4. Коля (hdmix.net) says:

    Хорошая статья, взял на заметку, нужно уделить должное внимание данному вопросу

  5. Дмитрий says:

    Володя, статья — огонь!
    Спасибо за подборку!

  6. Max says:

    Тут самое эффективное, по-моему, закрытие папки wp-includes, но в новых версиях WP правило с разрешением доступа к wp-tinymce.php не срабатывает почему-то. Может подскажете в чем проблема? Редактор tinymce некорректно отображается при данном правиле.

  7. Владимир Демянович (elims.org.ua) says:

    Max, не сталкивался с этой проблемой. не подскажу

Обсудить