Защита WordPress и усиление безопасности

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

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

Защищаем 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.

Убираем показ лишней информации

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

Открываем functions.php, лежащий в папке с активной темой нашего блога (wp-content/themes/название-вашей-темы/) и добавляем строчку:

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

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

Принудительное использование SSL

Если вы хотите, чтобы передаваемая вами информация была защищена, вам необходимо использовать SSL—протокол, обеспечивающий целостность и конфиденциальность обмена данными.

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

define('FORCE_SSL_ADMIN', true);

Эта константа включает принудительное использование SSL при заходе в панель администратора.

Используем .htaccess для защиты файла wp-config

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

Добавляем в файл .htaccess  следующие строки:

<files wp-config.php>
order allow,deny
deny from all
</files>

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

WordPress автоматически вставляет номер своей версии в исходный код страниц. Не всегда удаётся вовремя обновлять движок. А это означает, что зная какая у вас версия WordPress’a со всеми её брешами и слабыми местами, злоумышленник может очень-очень огорчить вас. Что делаем? Правильно, убираем вывод версии.

Открываем functions.php, лежащий в папке с активной темой нашего блога (wp-content/themes/название-вашей-темы/) и добавляем туда этот код —

remove_action('wp_head', 'wp_generator');

Мы запретили вывод информации о версии нашего движка.

Баним спамеров и ботов

Если Вам надоел какой-то постер и спамер, то решение – запретить ему доступ к сайту по 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.788

Пишем плагин для защиты от зловредных 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.

Личеры!

Мир полон добрых людей, которые изо всех сил пытаются донести до других новость или статью, написанную вами. Всё бы ничего, но ведь по доброте душевной они берут картинки прямо с наших с вами серверов, скромно забывая при этом про слово «трафик». А теперь представьте что будет, если ссылки на наши картинки попадут на какой-нибудь популярный китайский блог, с их-то почти уже четырёхсотмиллионным интернет-населением! Свят-свят-свят… Значит сейчас будем защищать хотлинкинг, a.k.a. личинг, a.k.a. «да я просто вставил ссылки на файлы с вашего сервера».

Apache поможет защищить нам наш трафик. В файле .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]

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

Переименование админа (Нет дефолтному юзернейму «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';

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

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

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

Options All -Indexes

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

Отключение 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