Apache: Скрытые 404 администраторская область, пока не аутентифицируется через основного автора, затем предоставьте доступ
Учитывая административную область с URL как это:
wp-admin/
wp-admin/whatever
wp-admin/another-page
wp-adminsecretlogin
Стандартное основное подлинное покрытие ввело бы подсказку имени пользователя и пароля на всех трех URL и возвратило бы 403 на всех неудавшихся подлинных попытках. Это - довольно очевидный сигнал, что что-то существует там и таким образом является приглашением на доступ сценария/грубой силы.
Я хотел бы вместо этого, потребовал бы основного автора везде, но при отсутствии аутентификации, не подсказка для имени пользователя и пароля, и вместо этого возвратите 404, не найденные ошибкой для всех URL кроме a wp-adminsecretlogin/ URL. В этом individual-to-the-site URL основной автор мог пройти и разблокировать остальную часть административной функциональности (хотя стандартный вход в систему приложения все еще будет необходим).
Как я сделал бы это через апачский .htaccess или .conf директивы?
Если предположить, что вы уже настроили что-то, требующее аутентификации на всех целевых URL (как wp-admin, так и на секретном URL), поместите это в блок вашего виртуального хоста:
RewriteCond %{LA-U:REMOTE_USER} ^$
RewriteRule wp-admin/ - [R=404]
Я не тестировал, так что я не совсем уверен, что это успешно закроет ответ 401, который обычно посылает фаза аутентификации, но это стоит попробовать.
. Базовая автоконфигурация отвечает 401, если пользователь/пасса неправильный. 403 (в контексте аутентификации) зарезервировано за аутентифицированными пользователями без прав доступа (т.е. у вас есть два пользователя на AuthUserFile, но также Require user1 и пытаться получить доступ с помощью user2 с правильным паролем)
403 также присутствует при попытке перечислить каталог напрямую без правильно настроенного autoindex/directoryindex, deny from directives, запрещающий правила mod_rewrite или mod_security, и т.д., поэтому обычно это не так уж и много указывает.
Запрос основного auth на Location /wp-adminsecretlogin и наличие RewriteRule, подобного тому, что предоставлен Шейном, может работать ([R] принимает только 30-кратные коды ошибок, так что он может возвращать 404 не корректно браузеру, а 301), но это в значительной степени зависит от вашего браузера и от того, как вы просматриваете вашу веб-страницу:
Поскольку веб-сервер требует аутентификации только по определенному пути, браузер не может представить основной автозаголовок для запросов, которые ранее не отправляли ответ 401, поэтому, если самый первый запрос от вашего браузера отправлен на /adminsecretlogin, он может работать (браузер предполагает, что все будет запрашивать базовый автозаголовок), но если вы ранее пытались получить доступ к / или /wp-admin (нет 401 ответа браузеру), браузер может "подумать", что эти другие контексты являются общедоступными и не представляют базовый автозаголовок, поэтому перезаписывающее устройство будет "отказывать" в доступе.