Italiano
Español
RomânăКак отключить возможность входа в систему?
Во время масштабной брутфорс-атаки я хочу полностью отключить возможность входа в WordPress. На сайте есть только мой аккаунт, поэтому посетителям не нужно авторизовываться, и это не ухудшит их опыт.
Когда мне потребуется войти, я могу удалить этот код. Альтернативно, я могу ограничить вход только по своему IP-адресу.
Я пытаюсь реализовать это, перехватывая попытки входа как можно раньше с помощью следующего кода:
if (isset($_POST['pwd']) || isset($_GET['pwd'])) {
header($_SERVER["SERVER_PROTOCOL"]." 404 Not Found");
echo 'Вход на сайт отключен';
die();
}
Это грубый метод, но он должен работать. Однако некоторые попытки входа все же проходят, и я не знаю, откуда они могут исходить.
Какими еще способами WordPress принимает авторизацию, если не через поле 'pwd'?
Существует ли стандартное решение для полного отключения входа в систему?
Примечание: помимо блокировки wp-login.php я удалил xmlrpc.php, который использовался как дополнительный вектор для брутфорс-атак. В моей текущей конфигурации он не нужен, но ваша может отличаться. Убедитесь, что он вам не требуется, перед отключением.
Это полезно, но я ищу способ полностью отключить логин с самого начала. У меня установлены Sucuri и другой плагин, которые предупреждают меня о brute force атаках. Я беспокоюсь, что это всё равно вызовет срабатывание этих плагинов.
Michael Khalili
@MichaelKhalili, на практике это невозможно, так как попытки входа могут поступать из самых разных источников. Если вы хотите заблокировать только wp-login.php или xmlrpc.php, это нужно делать на уровне конфигурации веб-сервера (в Apache можно использовать htaccess), чтобы PHP вообще не выполнялся. Единственное сравнимое по производительности решение на PHP потребует изменений в wp-config.php, а этот файл лучше лишний раз не трогать. Любое другое решение на основе PHP не будет работать лучше, чем предложенный ответ.
Mark Kaplun
Я разобрался с этим после того, как задал вопрос, и обновил свой пост. Я могу поместить код, который проверяет $_POST['pwd'], в must-use плагин (mu-plugins) и отключить xmlrpc.php. Это, кажется, решает проблему. Большая часть атак остановилась благодаря проверке $_POST['pwd'], а остальные прекратились после отключения xmlrpc.php.
Michael Khalili
Проблема с удалением файлов в том, что они вернутся при обновлении. Лучше заблокировать в htaccess, если вы не используете xmlrpc
Mark Kaplun
Отличное замечание, Марк. Думаю, в WordPress есть также настройка для отключения поддержки xmlrpc. Мне нужно выделить время, чтобы протестировать это. Я даже не уверен, какой механизм авторизации используется в этом файле.
Michael Khalili
Извините, но это очень плохая идея — размещать код в файле wp-config.php. Также я не вижу, чем ваш код отличается от другого ответа?
Johansson
Предыдущий ответ от Mark K был обновлен вами, Jack, вчера, исправив опечатку, которую я уже исправил.
Размещать код в wp-config — плохая идея, это было экстренное решение для тех, кто понимает, что они делают. Чем раньше мы вмешаемся, тем меньше ресурсов потребуется WordPress для блокировки входов.
Branndon
Тем, кто рассматривает этот вариант, следует помнить, что публичные AJAX-запросы по-прежнему отправляются в директорию wp-admin. Если ваш сайт использует AJAX, вам необходимо разблокировать путь к admin-ajax.php
Michael Khalili
И поскольку WP использует AJAX в ядре, это не следует делать нигде.
kaiser
Я согласен, что это не решение для "отключения" регистрации пользователей и входа в систему, что является вопросом здесь. Но @kaiser, почему вы говорите, что этого не следует делать? Я использую это на двух сайтах, которыми лично управляю, где регистрация пользователей отключена. Я также использую защиту паролем через .htaccess для файла wp-login.php. При правильной настройке AJAX-запросы и другие ресурсы из wp-admin (JS, CSS, изображения) не являются проблемой и могут значительно снизить вероятность успешных атак методом перебора.
cybmeta
@cybmeta ты переименовал wp-admin?
kaiser
Нет, я этого не делал. Это другой вариант, но он менее безопасен, URL админки сайта можно легко обнаружить, независимо от того, какое имя вы задали. В любом случае, это не объясняет, почему блокировка доступа к этому расположению вообще не должна выполняться. Также я не вижу, как изменение имени лучше, чем блокировка доступа к определенному расположению. Обратите внимание, что контекст в том, что никто кроме вас не будет обращаться туда, так почему блокировка доступа для всех остальных это плохо? В текущем случае, когда только вам разрешен доступ к wp-admin, я бы заблокировал wp-admin через .htaccess, даже если имя изменено.
cybmeta