Защита сайта на CMS «WordPress»

[STALKER_SLX]

В Интернете множество разного рода рекомендаций и советов по данной теме. Немного почитав статьи по этому вопросу, мне показались наиболее полными и полезными вот эти (также для большей наглядности привожу их основное содержимое):

10 Лучших Способов Защитить Свой Сайт От Взлома
https://unit-is.com/ru/support/articles/10-luchshiyi-sposobov-zasshitit-svoyi-sayit-ot-vzloma


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

1.1. Взлом платформы сайта, на котором размещается информация. Чтобы максимально обезопасить себя от этого, размещайте информацию на сайтах, на которых сложный язык программирования, а сервер не имеет выход из внутренней сети. Если имеется дополнительная аутентификация пользователей, то это будет для вас дополнительным плюсом к защите.

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

1.3. Слабая защита компьютера. Из-за отсутствия антивируса, пиратской операционной системы и из-за неустановленных обновлений, ваши секретные материалы могут быть похищены. Чтобы обезопасить себя, нужно настроить защиту, пользоваться брандмауэром и устанавливать необходимые обновления с официального сайта поставщика.

1.4. Отсутствие регулярного сканирования. Такая халатность может привести к тому, что вы можете лишиться всего, в один миг. Для сохранения информации, хранящейся на сайте, советуется проводить ежеквартальное сканирование PCI через сервис Trustwave.

1.5. Отсутствие патчей на систему. Невыполнения этого действия, зачастую, приводит к блокировке каких-либо данных. Злоумышленникам легче похитить информацию, если у вас не имеется последней версии патча. Им достаточно нажать одну кнопку, и вирус проникнет в центр обеспечения и лишит вас доступа к вашим же документам.

1.6. Брут – ещё одна уловка воров. Брут похож на взлом пароля, но он происходит по иной схеме. Если взлом пароля происходит по считыванию информации, то брут – это взлом пароля с помощью метода подбора. Конечно, у вас может быть сложный пароль и состоять из цифр, но если в пароле указывается своё имя и год рождения, то для хакеров это будет просто подарком. Также этим методом вычисляется похожий пароль на других сервисах, поэтому не используйте один и тот же пароль на разных сайтах и чаще меняйте пароль. Это касается и паролей от FTP, пользователей баз данных и учетных записей на сайте.

1.7. Ещё один проверенный способ защиты – это защита с помощью файлов .htaccess. Эти файлы помогают настраивать и улучшать безопасность сайта. Благодаря им можно установить множество дополнительных конфигураций, которые помогут выстроить систему защиты от взлома. Также, благодаря файлу .htaccess редактирование параметров системы будет для вас более безопасным, потому что это происходит без затрагивания основного конфигурационного файла, а значит, сбой системы из-за удаления системного файла почти исключён.

1.8. Протокол SSL – ещё один незаменимый помощник в охране сайта. Благодаря ему устанавливается безопасное соединение между сервером и браузером пользователя. Информация передаётся в закодированном виде по HTTPS. Взломать сайт становится намного сложнее, потому что расшифровать кодировку может только специальный ключ, который хакерам приносит множество трудностей и усложняет задачу.

1.9. Взлом без применения технических средств. Этим методом пользуются редко, но он действует. Для получения пароля, злоумышленники представляются работниками технической поддержки или администраторами и просят пароль. Вы называете его и навсегда прощаетесь с вашими документами. Мера защиты для этого способа одна: будьте внимательны, кому вы называете свою информацию для входа в аккаунт.

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


2. Как Защитить Свой Сайт Или Блог Под Управлением CMS Wordpress От Взлома: Практические Советы.
https://unit-is.com/ru/support/articles/kak-zasshitit-svoyi-sayit-ili-blog-pod-upravleniem-cms-wordpress-ot-vzloma


2.1. Защищаем Wordpress от XSS-инъекций.

2.1.1. Если вы хоститесь на виртуальном кластерном хостинге или на виртуальном сервере (VPS) в случае использования в качестве веб-сервера Apache, вставьте код в файл .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]

Данный код позволяет проверять все возможные запросы. Но, если же запрос содержит тег или, возможно, попытку модифицировать значение переменных GLOBALS и _REQUEST, тогда он попросту блокирует его и выдаёт пользователю ошибку 403.

2.1.2. В случае с VPS и установленным NGINX как самостоятельным веб-сервером (+ php-fpm), в последних версиях разработчиком внедрена штатная защита NAXSI (NGINX ANTI XSS & SQL INJECTION).
Файервол веб-приложений (WAF) для NGINX, который помогает в защите от XSS, SQL-инъекций, CSRF, а также Local & Remote File Inclusions.

Установка в Ubuntu, Debian, Netbsd, Freebsd: возможно в виде пакета.

К примеру, в серверной Ubuntu 12.04 достаточно сделать:
apt-get install nginx-naxsi

Также и других Linux-систем. Если пакеты еще не появились, тогда собираем nginx + naxsi из готовых исходников:

wget http://nginx.org/download/nginx-x.x.xx.tar.gz
wget http://naxsi.googlecode.com/files/naxsi-x.xx.tar.gz
tar xvzf nginx-x.x.xx.tar.gz
tar xvzf naxsi-x.xx.tar.gz
cd nginx-x.x.xx/

(вместо x.x.x.x — необходимо поставить доступные актуальные версии)

Необходимо раскомментировать в конфигурации NGINX включение базовых запретительных правил
include /etc/nginx/naxsi_core.rules;

и уже после перезапустите конфигурацию (service nginx reload).

Если при попытке зайти в админ панель CMS Wordpress вы ошибётесь с вводом логина или пароля, движок незамедлительно вам об этом сообщит. Зачем хакеру знать, что пароли, который он подбирает – неверены?


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

Следует открыть файл functions.php, который лежит в папке с активной темой блога (wp-content/themes/название-вашей-темы/) и, непосредственно,
добавить следующий код:
add_filter('login_errors',create_function('$a', "return null;"));

Сохраняем файл. Теперь никаких сообщений.

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

Если вы хотите, чтобы информация, которую вы передаете, была защищена, тогда вам необходимо использовать SSL-протокол, который обеспечивает целостность и конфиденциальность обмена данными. В отдельных случаях это может затруднить работу процесса подбора паролей роботами. В Wordpress'e это сделать очень просто.
Прежде всего, узнаём, есть ли возможность на вашем тарифном плане использовать SSL. Если да, то открываем файл wp-config.php (в корне сайта) и добавляем следующее:
define('FORCE_SSL_ADMIN', true);


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

wp-config.php содержит абсолютно все данные, которые необходимы для подключения к нашему серверу MySQL, а также к базе данных. Защитить доступ – одна из самых главных и сложных задач.
В первую очередь необходимо найти файл .htaccess в корне нашего сайта, далее добавить следующие строки:
order allow,deny
deny from all


2.5. Сокрытие версии Wordpress
Движок автоматически вставляет номер текущей версии CMS в исходный код каждой страницы. Не всегда есть время или возможность обновить движок. А это значит, что человек знает, какая версия Wordpress'a стоит, знает, какие слабые места на вашем сайте еще присутствуют. Что следует делать? Необходимо убрать добавление в исходный код версии CMS WordPress.

Открываем functions.php, и добавляем:
remove_action('wp_head', 'wp_generator');

Желательно также удалить файл readme.html в корневой папке сайта. В нём тоже содержится информация о текущей версии Wordpress.


2.6. Убиваем админа! Нет дефолтному юзернейму «admin».
Злоумышленникам намного легче получить доступ к вашему сайту при помощи брута, особенно, если логин уже известен. Легче всего взломать сайты, если стоит стандартный логин «admin» для администирования сайта.
В версии 3.0 CMS WorsPress и выше, имеется возможность изменить стандартный логин для администратора. Для всех остальных (ранних) версий необходимо выполнить один SQL-запрос (например, через phpMyAdmin):
UPDATE wp_users SET user_login = 'Ваш новый логин' WHERE user_login = 'Admin';


2.7. Организация предварительной аутентификации на файле wp-login.php

Как правило, первым попадает под удар файл входа в административную панель wp-login.php. Самый простой метод защиты, это скрыть этот файл (переименовать или сделать доступным на произвольном порту). Но иногда такие методы приносят массу неудобств, к примеру для блогов с большим количеством зарегистрированных подписчиков и редакторов.
Введем предварительную авторизацию с использованием HTTP Auth Basic средствами PHP, конфиги веб-сервера трогать не станем, что придаст методу наибольшей универсальности.

Создаем файл preauth.php со следующим кодом:
$p = "md5_hash_of_pass";
$u = "Login";
function a() {
   header('WWW-Authenticate: Basic realm="Administration Area"');
   header('HTTP/1.1 401 Unauthorized');
   if ($_SESSION['pre']!=1) echo 'Preauthentication required!';
   $_SESSION['pre']='';
   exit;
}
if (!isset($_SERVER['PHP_AUTH_USER']) or !isset($_SERVER['PHP_AUTH_PW'])) {
a();
} else if($_SERVER['PHP_AUTH_USER'] == $u and md5($_SERVER['PHP_AUTH_PW']) == $p) {
 echo 'Preauthenticated!';
} else {
echo('Preauthentication failed!');
$_SESSION['pre']=1;
a();
}
?>


Где $p – заранее сгенерированный md5-хеш пароля, $u – логин (не устанавливайте те же логин и пароль, что используете для входа через штатную форму авторизации, иначе смысл метода потеряется).

Модифицируем файл wp-login.php, прописываем код в самом начале файла, после "
include('preauth.php');

Теперь при обращении по адресу http://мойсайт/wp-login.php, будет запрошен логин и пароль из файла preauth.php. В случае корректного ввода, отобразится штатная форма авторизации Wordpress. Метод не только вдвойне затруднит подбор паролей злоумышленником, но и предоставит неожиданность ботам, которые вряд ли ожидают такой ответ от стандартной формы входа движка. Стоит учесть, что файл wp-login.php будет перезаписан при обновлении CMS, поэтому необходимо прописать строку "include('preauth.php');" повторно.


ВОПРОСЫ

1. Учитывая, что указанная информация на текущий момент времени может быть уже устаревшей или неполной, а вредители ведь не дремлют ни минуты, прошу помощи у практикующих ИТ-профессионалов разобраться в этом очень важном и актуальном вопросе - как защитить сайт на CMS «WordPress».

2. Организация защиты будет отличаться в случае Apache и Nginx. В связи с чем, также прошу Вас, уважаемые форумчане, не обделить своим вниманием этот существенный момент, а осветить на сколько возможно.

[Уваров А.С.]

Написано много и разного, в принципе откровенно вредных советов нет - есть бесполезные.

Основные причины взлома WP и CMS в общем:

1. Слабые пароли. Причем слабым считается не только пароль типа 123, но и тот, который может быть легко вычислен. Типовые слабые пароли: даты рождения, имена детей, собак и т.д.

2. Варез. Кто не любит халявы? Нуленые версии тем и плагинов могут содержать бекдоры, а могут и не содержать, но так как вы лишены обновлений в них могут оказаться незакрытые уязвимости, через которые вас могут взломать.

3. Отсутствие обновлений. Тут все просто и понятно. Причем способ с убиранием версии CMS в коде вас не спасет, никто не мешает злоумышленнику опробовать на вас пару тройку ходовых эксплойтов.

4. Админский доступ третьих лиц. Часто доступ к сайту имеют несколько человек, часть из них временно. Но эти аккаунты остаются активными. Причем, даже если вы уверены в порядочности этого человека, то нельзя исключать ситуации, что пароль у него просто украдут.

5. Уязвимости в серверном ПО. Если у вас сервер пару лет не обновлялся, содержит парк разного ПО сомнительной необходимости и т.д. и т.п. то вопрос "взломают ли вас" не стоит, а стоит вопрос "когда это случится". Хороший администратор должен всегда знать что за службы крутятся у него на сервере, какие у них конфиги и для чего нужен тот или иной пакет. Поэтому покупая очередной VPS мы сразу переустанавливаем его на "минимальную" установку, т.е. чистая система без всякого предустановленного софта.

Что касается непосредственно WP. Штатная установка вполне безопасна при условии регулярных обновлений и нормально выставленных прав на папки и файлы. Единственно, желательно закрыть админку через дополнительную аутентификацию средствами веб-сервера, так как несколько лет назад по сети гулял вирус брутфорсящий админку WP, эффект от которого можно было сравнить с небольшой DDoS-атакой. На слабых серверах WP начинал ложиться.