Тема статьи: как забота хостера может вызвать беспокойство у клиента? Хостер ставит защиту на сайт клиента (минуя меня, то есть разработчика), а клиент в итоге не может войти на сайт. Вот с такой проблемой столкнулись некоторые из моих клиентов, а значит и я. Решение читайте ниже.
Подробнее:
Периодически мой любимый хостер — reg.ru (ссылка рефферальная;)) — начинает активно беспокоиться о безопасности моих (и чужих) сайтов и рассылать емейлы с темой «Обнаружена попытка взлома ваших сайтов». В письме приведено несколько рекомендаций, но особенно привлекает внимание следующее предложение:
«В связи с обнаружением Brute-force атаки, на страницы доступа к административным панелям всех Ваших сайтов использующих CMS Joomla и WordPress была установлена дополнительная базовая HTTP-аутентификация средствами .htaccess.»
Спасибо большое! Безопасность прежде всего. Дополнительная HTTP-аутентификация ставится на все сайты, в которых определено присутствие популярной CMS. То есть, даже если ваш сайт закрыт от индексирования, то есть возможность его открытия кем-то, а значит и взлома, очень мала, все равно, на нем поставят дополнительную защиту.
И даже, если ваш сайт на wordpress уже защищен максимально, как только можно (что я обычно делаю для всех клиентских сайтов), все равно добрый хостер поставит защиту. За что ему искреннее спасибо, потому что всегда лучше перебдеть!
Но в случае установки защиты клиент не сможет попасть в админ-панель сайта тем способом, как он привык делать. Он набирает известный ему адрес админки (который может отличаться от стандартного) и видит дополнительное всплывающее окно для ввода пароля:
Это и есть так называемая HTTP-аутентификация. Прописывается она в файле .htaccess. Файл этот по умолчанию располагается в папке с файлами wordpress.
Для клиентов это очень неудобно. Защита, конечно, убирается быстро, достаточно зайти по ftp и почистить .htaccess, но ведь она может появиться опять! Кроме того, если .htaccess расположен в корневой директории хостинга, а сайты располагаются во вложенных папках (так бывает), то окно будет выскакивать на всех сайтах, даже если вы почистите вложенные файлы .htaccess.
В чем, собственно, состоит защита? Все очень просто — делается проверка на попытку получения доступа к файлу wp-login.php — который как раз отвечает за авторизацию в системе (причем, не только в админке, так что, если вы ведете проект с возможностью авторизации пользователей, то для вас проблема еще актуальнее).
Решение, которое напрашивается само собой — переименовать файл wp-login.php. Чтобы попытка прямого обращения отдавала 404 ошибку, но можно было легко зайти по измененному адресу, а так же, чтоб это никак не сказалось на самом движке.
Как ни странно, во всех известных мне плагинах, обеспечивающих безопасность в wordpress — better wp security, wordfence, bulletproof security — есть опция для изменения пути доступа в админку (папка wp-admin), но нет опции изменения самого файла wp-login.php. Хотя напрямую при использовании этих плагинов вы его открыть все равно не сможете — получите 404.
Возможно, у вас будут какие-то еще причины переименовать этот файл. Тогда вам тоже пригодится данное решение.
Решение:
Поиск в google помог найти лишь жалкую горстку статей на эту тему, хотя и одно действительно рабочее решение — плагин «Rename wp-login.php» После его установки и активации вам сразу открывается страница настроек ЧПУ, где добавляется новое поле, в котором можно задать новое название для нужного нам файла.
Теперь при попытке перейти по адресу http://ВАШ_САЙТ/wp-login.php вы получите 404 ошибку, зато по измененному адресу можно спокойно попасть в админку (естесственно, после логина и пароля), даже если на сам файл повешена HTTP-аутентификация, или еще какие правила в .htaccess (deny for all, например). Обратите внимание, что плагин заявлен как «неподдерживаемый». Я не увидел никаких проблем с его использованием, но все равно советую вам провести тестирование, если вы используете различные способы авторизации на сайте — напрямую, через соц.сети, через сторонние плагины.
