G|Translate: English EN Deutsch DE Italiano IT Русский RU Español ES Українська UK

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

5/5 - (1 голос)

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

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

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

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

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

Закрываем папки и файлы WordPress с помощью 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>

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

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

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

Можно добавляем в .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)

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

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

Закрываем папки и файлы WordPress с помощью 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

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

Вариант 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, результат прекрасен

Закрываем папки и файлы WordPress с помощью 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

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

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

Итоговый код для .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

TSL плагины

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

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

 

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

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

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

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

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

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

TSL плагины

 

Подпишитесь в VKontakte - нажмите кнопку
Подпишитесь в Telegram - нажмите кнопку
Наша группа ODNOKLASSNIKI

Вы можете сохранить ссылку на эту страницу себе на компьютер в виде htm файла




Пишите на электронную почту (тема и email будут добавлены автоматически в письмо)

В Вашем браузере должна быть настроена обработка ссылок mailto

site_post@bk.ru

или просто скопируйте адрес e-mail



Почитать в разделе

Защита WP

CMS WordPress является достаточно популярной платформой для ведения блогов и создания сайтов. Это же автоматически подразумевает большое количество желающих использовать Ваш сайт для своих целей: перехват и перепродажа трафика (т.е. пользователь пришел на Ваш сайт и редиректом ушел на целевой сайт хакера) размещение рекламных ссылок создание бота на Вашем сервере/сайте (будет использоваться как минимум для подбора паролей на чужих сайтах) отправка спама (да, у WordPress есть свой почтовый сервер) добавление к Вашему сайту рекламных страниц (достаточно дописать в базу MySql) Самое обидное - что сайт живет после взлома не более 6 мес. Поисковые роботы находят всё это...
(Читать полностью...)

  • Всего статей в разделе: 12
  • Показано статей в списке: 11
  • Сортировка: название по алфавиту

Бан хакеров по IP для WordPress

Нехороших хакеров можно и нужно банить по IP - т.е. не пускаем пакеты с отдельных IP в обработку. Но есть ряд проблем: часть IP (с которых идет атака) принадлежат не хакерам, а вполне обычным пользователям, которые наловили вирусов на свой ПК (и теперь он работает на другого хозяина) с учетом ежедневной смены IP провайдером у большей части обычных пользователей - через сутки конкретный IP станет не опасным есть упрямые хакеры, которые работают с постоянного IP еще есть "умники", которые пытаются запустить разные php-скрипты в адресной строке браузера (в основном получают, конечно, код 404) есть принципиально разные блокировки IP на уровне CMS WordPress на уровне...
(Читать полностью...)

Блокируем ботов-подборщиков через fail2ban

80% всех атак ботов на WordPress идут на вход в административную панель. Наша задача - такие IP отправить в бан. Используем плагин WP fail2ban. Плагин делает важную  вещь — он выводит в лог /var/log/auth.log (это один из системных логов Linux) каждую попытку авторизации на сайте (настройками можно изменить). Т.е. не создается дополнительный лог-файл - а идет запись в один общий системный лог Linux. Это удобно, если у Вас несколько сайтов на VPS, всё ошибки входа по всем сайтам будут записываться в один общий файл. И не нужно дополнительно под каждый сайт настраивать WP fail2ban:) ВАЖНО: можно вообще "спрятать" админку от злых ботов Меняем адрес административной панели...
(Читать полностью...)

Варианты основных хакерских атак на Ваш сайт

Зачем защищать небольшой сайт? "У меня маленький сайт-блог, зачем мне его защищать и от кого?" Немного печальной статистики. Скажем так, сейчас в 50% на Вашем сайте пасутся боты, а не живые люди.  Вот классический пример работы ботнета - с разных IP (зараженные ПК пользователей) идет подбор пароля к логину Administrator - аккуратно, с интервалом в 5-10 минут. Успехов тебе,  железяка :) Всё, что видит ботнет со своей стороны - после однократного ввода логина/пароля форма входа исчезает...  Как видно на картинке выше - атака перебором идет с разных IP (разные заражённые ПК), которые через небольшой интервал времени меняются. Т.е. необходимо запоминать (с помощью плагина) IP,...
(Читать полностью...)

Двухфакторная аутентификация WordPress

Включаем двухфакторную аутентификацию WordPress - т.е. логин + пароль для входа + еще дополнительный код/пароль. Защита паролем сервера Апач Общая структура папки Вашего сайта на WordPress (на сервере хостинга) следующая Сайт сайт запускается файлом index.php в корневой папке. Административная панель запускается файлом index.php в папке wp-admin Существует два варианта входа в систему управления сайтом: через браузер в административную панель вход или site.ru/wp-admin (тут расположена сама панель управления) или site.ru/wp-login.php (проверка логина/пароля) через мобильное приложение (Android / iOS), см. ниже - указываем логин/пароль и сайт (уже без "хвостика"...
(Читать полностью...)

Защита базы данных сайта MySql

База данных на сервере хостинга - основное место, где хранятся "детальки" (текстовые данные в основном) от Вашего сайта. Если туда что-либо записать лишнего - то движок WordPress это и покажет = и это уже будет не Ваш сайт :( Зачем нужна вообще какая-то база для сайта? Читаем статью База MySql Прямая атака на базу MySql По умолчанию, при установке WordPress создает в базе таблицы с префиксом wp_. Злоумышленники об этом знают. Необходимо либо при установке выбрать другой префикс вида mysite_ (WordPress спросит при установке, не более 6-ти латинских букв), либо поменять его у готового сайта. Зачем это нужно? Ну вот пример - мы при установке указали другой префикс вида xxx_...
(Читать полностью...)

Защита текста и картинок от копирования

Как защитить свой блог (картинки и текст) от копирования? В общем случае - никак :(  Всё, что Вы видите в своем браузере - оно уже есть на Вашем компьютере. Но можно сильно усложнить сам процесс копирования для любителей copy-paste. Итак, основные направления: запрет выделения текста мышью и дальнейшее copy-paste запрет хотлингов (т.е. показывать картинки с Вашего сайта на другом домене) защита картинок через "водяной знак" (он же Watermark) запрет парсинга страницы сайта с другого домена   Запрет выделения текста мышью (запрет копирования) Казалось бы самый простой вариант - заблокировать правую кнопку мыши. Но это не есть хорошо. Часть посетителей...
(Читать полностью...)

Как сбросить пароль администратора WordPress

Потеряли пароль от админики WordPress? Что делать? Не всё так плохо :) Используем средство восстановления пароля WordPress При входе Вводим свой email Получаем на свою почту служебную ссылку, заходим, меняем пароль. Всё стандартно. Используем нашу базу MySql для смены пароля Да, в ней хранится информация о пользователях, их паролях и прочая полезная информация. Для прямого подключения к базе используем phpMyAdmin (параметры входа у Вас должны быть от Вашего хостера). Вот база данных и таблица wp_users Хакеры, не мучайтесь, все критичные данные замазаны, Administrator - это ник, а не логин :) Пароль пользователя в базе хранится в зашифрованном виде. Делаем Sql-запрос...
(Читать полностью...)

Как скрыть логин автора поста

При отображении записи WordPress выводит автора поста. Как отключить вывод автора поста/записи? Если ничего не  делать - то любой желающий сможет увидеть логин входа в систему и ему останется только подбирать пароль. И да -  WordPress в стандартной установке еще и подтверждает правильность логина. И вот тут нас поджидает проблема. Вывод автора поста делает не сам движок WP - это зависит от применяемой темы. В каких-то темах автор выводится, в каких-то темах автор не выводится, в каких-то настраивается. Есть специальный плагин - но он работает не на всех темах (именно по этой причине, что в разных темах сделано иногда по разному). Итак, что мы можем сделать. Плагин Show/Hide...
(Читать полностью...)

Как скрыть логин пользователя WordPress

Посмотрим статистику. Для начала устанавливаем плагин Activity Log (логгирование действий пользователей), активируем И видим следующие картину Кто все эти люди и откуда они знают мой логин? Это не люди мучают клавиатуру с ручным подбором паролей, это боты (зараженные компьютеры). Точнее даже не компьютеры, а устройства типа микроволновки и холодильника. Сейчас везде производители ставят процессоры и выход в интернет, на таких устройствах практически нет никакой защиты, их взламывают и они вливаются в ряды ботов. Еще есть «банды умных лампочек» – smart-лампы с управлением со смартафона через Wi-Fi. Тоже хорошо взламываются и начинают работать на чужих дядей. WordPress достаточно...
(Читать полностью...)

Переводим сайт WordPress на https

Будем переводить сайт на защищенный протокол HTTPS ВАЖНО: Это именно зашифрованная передача данных от сервера до конечного посетителя, а не показатель безопасности сайта! Сайт может быть взломан, сайт сам по себе может быть сделан мошенниками и прочее - и при этом сайт будет работать по защищенному протоколу https и иметь "зеленый замочек". Поэтому сейчас зеленый цвет замочка остался только в Opera, остальные браузеры показывают его серым цветом. Переводим на HTTPS Читаем основную статью Как включить HTTPS на сайте? Для работы HTTPS нам нужно несколько базовых вещей: нужно получить сертификат SSL (браузер как-то должен проверить валидность ключа для...
(Читать полностью...)

Плагины для архивирования и переноса сайта

Лучшая безопасность для сайта - это делать backup сайта. И регулярно. Даже если враги всё сломали (а там почти 3000 файлов PHP в движке) - всё удаляем из папки WWW на сервере (именно ВСЁ - включая файлы движка WordPress) и восстанавливаем из бэкапа как было. Что такое архивация сайтов? Backup сайта это копирование баз данных, файлов сайта, почты, FTP-аккаунтов и множества других "деталек" на Вашем хостинге. Сайт у нас состоит собственно из нескольких частей: набор файлов (файлы PHP движка и картинки) база данных MySQL, в которой хранится текстовая часть сайта, меню и все взаимосвязи между модулями Не обязательно, кстати,  именно PHP - для разработки сайта может быть...
(Читать полностью...)