Закрываем папки и файлы WordPress с помощью Apache

Используем web-сервер Apache для блокировки доступа извне

ВАЖНО: всё нижеперечисленное будет работать, если Вы конечно, используете сервер Apache.

Если Вы используете связку NginX и  PHP-FPM (сервера Apache тут нет!)

все эти инструкции работать не будут! Сервер Apache не участвует в обработке запросов!

Закроем файл wp-login.php

Мы можем спрятать вход в административную панель. И ввод логина/пароля не будет уже использовать напрямую файл wp-login.php.

Но сам файл wp-login.php конечно продолжает существовать и работать, просто теперь WordPress при его запросе показывает ошибку 404. Но как мы помним, ботнетов много – и они по прежнему будут загружать Ваш сервер PHP на обработку ошибки 404. 

И тут вступает в дело Apache – установим пароль на доступ к файлу wp-login.php

<Files wp-login.php>
AuthType Basic
AuthName "That's protected Area!"
AuthUserFile ...полный путь на сервере..../.htpasswd
require valid-user
</Files>

К файлу с паролем необходимо указать полный путь на сервере

Наслаждаемся результатом (при неправильном вводе пароля)

Можно добавляем в .htaccess полный запрет на доступ к wp-login.php – но лучше так не делать:

• на стандартном WordPress (без измененного доступа к админпанели) – Вы себе полностью заблокируете вход
• перестанут работать страницы WP с паролем – они тоже обращаются к wp-login.php

<Files wp-login.php>
<IfModule mod_authz_core.c>
Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
Order deny,allow
Deny from all
</IfModule>
</Files>

ВАЖНО: данный вариант с полной блокировкой будет работать только при условии, если у Вас внутри WordPress на входе установлена внутренняя переадресация (изменен адрес административной панели).  Тогда обращение к  wp-login.php происходит уже внутри WP.

Закроем файл wp-config.php

блокируем доступ к файлу /wp-config.php и всем вариантам его подбора (что бы WP не тратил ресурсов на выдачу 404)

6 попыток подбора в минуту, причем еще с разных IP (работает ботнет) – на всё это безобразие  WP должен выдавать 404 (совсем ненужная работа сервера).

Поможем WordPress, добавляем в .htaccess

<Files wp-config*>
<IfModule mod_authz_core.c>
Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
Order deny,allow
Deny from all
</IfModule>
</Files>

wp-config* означает, что вместо * могут быть любые символы. Всё – у подборщиков получается  403 ошибка от Apache

Установим пароль сервера для доступа в административную панель

ВАЖНО: не надо закрывать всю папку /wp-admin/, там живет файл /wp-admin/admin-ajax.php – который используется движком WordPress

Нам нужно поставить пароль только на индексный файл в этой папке (который собственно и запускает админку)

DirectoryIndex index.php
#принудительно вызвать индекс
#потом пароль на этот файл
<Files index.php>
AuthType Basic
AuthName "That's protected Area!"
AuthUserFile ...полный путь на сервере..../.htpasswd
require valid-user
</Files>

Место расположения файла .htpasswd (логин/пароль сервера) должно быть указано по полному пути сервера!

После ввода логина/пароля WortdPress система попросит дополнительный пароль сервера

Закроем файл xmlprc.php

У WordPress еще есть вторая админка – для управления блогом через мобильное устройство. Есть приложение WordPress, через которое Вы можете редактировать свой сайт (после ввода своего логина и пароля, конечно).

Если Вы этим не пользуетесь – проще ее заблокировать совсем. За вход через мобильное приложение отвечает файл xmlprc.php в корневой папке Вашего блога.

Вариант 1. Блокируем его через плагин, который умеет это делать. Например, плагин Webcraftic Clearfy

Вариант 2. Запрещаем доступ к этому файлу на уровне Apache (через дополнительную инструкцию в файле .htaccess)

<Files xmlrpc.php>
<IfModule mod_authz_core.c>
Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
Order deny,allow
Deny from all
</IfModule>
</Files>

Два варианта инструкций под разные версии сервера Apache, результат прекрасен

Доступ заблокирован с ошибкой 403, запрос до сервера PHP не дошел, лишней нагрузки на сервер не было

А вот так выглядят логи сервера Apache после настроенной защиты – client denied (запрещено клиенту)

04:32:18 [client 111.229.111.211]  client denied: /wp-login.php
04:32:20 [client 111.229.111.211]  client denied: /wp-login.php
04:32:21 [client 111.229.111.211]  client denied: /xmlrpc.php
04:44:24 [client 157.245.62.87]  client denied: /wp-login.php
04:44:25 [client 157.245.62.87]  client denied: /wp-login.php
04:44:26 [client 157.245.62.87]  client denied: /xmlrpc.php
04:58:48 [client 2a03:b0c0:1:d0::109c:1]  client denied: /wp-login.php
04:58:48 [client 2a03:b0c0:1:d0::109c:1]  client denied: /wp-login.php
04:58:48 [client 2a03:b0c0:1:d0::109c:1]  client denied: /xmlrpc.php
05:28:31 [client 114.7.197.82]  client denied: /wp-login.php
05:28:32 [client 114.7.197.82]  client denied: /wp-login.php
05:28:33 [client 114.7.197.82]  client denied: /xmlrpc.php
05:42:05 [client 149.202.59.123]  client denied: /wp-login.php
05:42:05 [client 149.202.59.123]  client denied: /wp-login.php
05:42:06 [client 149.202.59.123]  client denied: /xmlrpc.php
05:51:01 [client 52.187.67.97]  client denied: /wp-login.php
05:54:01 [client 14.248.83.23]  client denied: /wp-login.php
06:08:37 [client 195.154.29.107]  client denied: /wp-login.php
06:08:43 [client 195.154.29.107]  client denied: /wp-login.php
06:08:43 [client 195.154.29.107]  client denied: /xmlrpc.php
06:22:00 [client 159.65.128.55]  client denied: /wp-login.php
06:22:06 [client 159.65.128.55]  client denied: /wp-login.php
06:22:07 [client 159.65.128.55]  client denied: /xmlrpc.php

Файл PHP (который запрашивается) и IP ботнета выделен красным цветом.

Каждый  бот делает по три подхода – два на wp-login.php и один на xmlrpc.php. Видите, какой глупой работой ночью (пока Вы спите) может заниматься Ваш сайт без настроенной защиты. Ему приходится обрабатывать каждый некорректный вход с логином/паролем. А так сервер Apache на входе всех разворачивает.

И с интервалом в 5-10 сек. И бот идет дальше, получив 403 ошибку от сервера.

Не пускаем ботов в админку WP (wp-login.php и xmlrpc.php)

Запрещено же – но нет, боты с первого раза не верят.

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

• закрыть/ограничить доступ через Apache к файлам  wp-login.php и  xmlrpc.php
• отдавать рандомно коды 200 (ОК), 404 (Not Found), 403 (Forbidden)  и 301 (перемещено) на эти файлы

Видно, что ботнет делает два запроса на wp-login.php, получает два запрета 403, делает один запрос на xmlrpc.php, тоже получает запрет 403 – и уходит.

Что будет делать ботнет, получая разные рандомные коды сервера  при каждом запросе и при этом не получая возможности куда-либо ввести данные? Сойдет он с ума или нет?

А вот так без защиты:

• перебор авторов по ID
• запрос списка авторов через JSON
• перебор логин/пароль через мобильный вход xmlrpc.php

51.79.111.220 - [01:13:46] "GET / HTTP/1.0" 200 75023 
51.79.111.220 - [01:13:46] "GET //?author=1 HTTP/1.0" 301 339 
51.79.111.220 - [01:13:46] "GET //?author=2 HTTP/1.0" 301 339 
51.79.111.220 - [01:13:47] "GET //?author=3 HTTP/1.0" 301 339
51.79.111.220 - [01:13:47] "GET //?author=4 HTTP/1.0" 301 339
51.79.111.220 - [01:13:48] "GET //wp-json/wp/v2/users/ HTTP/1.0" 200 1152 
51.79.111.220 - [01:13:48] "POST //xmlrpc.php HTTP/1.0" 200 629 
51.79.111.220 - [01:13:49] "POST //xmlrpc.php HTTP/1.0" 200 629 
51.79.111.220 - [01:13:50] "POST //xmlrpc.php HTTP/1.0" 200 906 
51.79.111.220 - [01:13:51] "POST //xmlrpc.php HTTP/1.0" 200 906 
51.79.111.220 - [01:13:52] "POST //xmlrpc.php HTTP/1.0" 200 906 
51.79.111.220 - [01:13:53] "POST //xmlrpc.php HTTP/1.0" 200 906 
51.79.111.220 - [01:13:53] "POST //xmlrpc.php HTTP/1.0" 200 906 
51.79.111.220 - [01:13:54] "POST //xmlrpc.php HTTP/1.0" 200 906 
51.79.111.220 - [01:13:55] "POST //xmlrpc.php HTTP/1.0" 200 906 
51.79.111.220 - [01:13:55] "POST //xmlrpc.php HTTP/1.0" 200 593 
51.79.111.220 - [01:13:56] "POST //xmlrpc.php HTTP/1.0" 200 593 
51.79.111.220 - [01:13:57] "POST //xmlrpc.php HTTP/1.0" 200 906 
51.79.111.220 - [01:13:57] "POST //xmlrpc.php HTTP/1.0" 200 906 
51.79.111.220 - [01:13:58] "POST //xmlrpc.php HTTP/1.0" 200 593 
51.79.111.220 - [01:13:59] "POST //xmlrpc.php HTTP/1.0" 200 906 
51.79.111.220 - [01:13:59] "POST //xmlrpc.php HTTP/1.0" 200 906 
51.79.111.220 - [01:14:00] "POST //xmlrpc.php HTTP/1.0" 200 906 
51.79.111.220 - [01:14:01] "POST //xmlrpc.php HTTP/1.0" 200 906 
51.79.111.220 - [01:14:06] "POST //xmlrpc.php HTTP/1.0" 200 906 
51.79.111.220 - [01:14:08] "POST //xmlrpc.php HTTP/1.0" 200 906 

Обратите внимание на временные интервалы!

За 20 минут с одного IP 51.79.111.220 было совершено 26 попыток.

Одноядерный процессор вынужден работать под 100% нагрузкой. На реальных посетителей сайт уже ресурсов сервера не хватит.

После закрытие доступа к трем основным файлам (wp-login.php, xmlprc.php и wp-config.php) нагрузка на сервера падает в несколько раз – ниже скан нагрузки от Beget

Это видно даже визуально.

Итоговый код для .htaccess  в корневой папке – дописываем после # END WordPress

# pass wp-login.php ------------------------------------
<Files wp-login.php>
AuthType Basic
AuthName "That's protected Area!"
AuthUserFile ...полный путь на сервере..../.htpasswd
require valid-user
</Files>
# block xmlrpc.php --------------------------------------
<Files xmlrpc.php>
<IfModule mod_authz_core.c>
Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
Order deny,allow
Deny from all
</IfModule>
</Files>
# block wp-config* ----------------------------------------
<Files "wp-config*">
<IfModule mod_authz_core.c>
Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
Order deny,allow
Deny from all
</IfModule>
</Files>

Закроем доступ к папке с плагинами по прямому пути

тут совсем просто –  в папке /wp-content/plugins/ помещаем файл .htaccess с одной записью, мы закрываем и текущую папку и все папки плагинов.

ВАЖНО: часть плагинов может перестать работать – объяснение ниже!

deny from all

В чём может быть проблемы в работе плагинов? Если плагин делает что-то полезное с выводом на сайте, то ему нужно, как правило:

• скрипт JS
• файл стилей CSS

Да, эту информацию с помощью PHP можно просто в код сайта добавить, но обычно используют через подключение внешних файлов. А эти файлы как раз и лежат в папке плагина – т.е. по адресу /wp-content/plugins/my-plugin

При запросе внешним клиентом страницы сайта данные файлы должны подключиться… А не смогут, т.к. полностью перекрыт доступ в папки плагинов.

В самом WordPress в общей папке с плагинами лежит файлик index.php

Да – “молчание – золото”. Т.е. при запросе данной папки /wp-content/plugins/ любопытный товарищ ничего (списка папок плагинов) не увидит.

Читаем статью

TSL плагины