Еще пара уловок для защиты блога на wordpress
В нарушение всех планов на написание постов хочу дополнить предыдущий пост о защите блога на wordpress, а точнее о защите файлов и папок средствами .htaccess. В корне наших блогов лежат файлы wp-login.php и wp-config.php, которые особенно интересны злоумышленнику, ну и нам их без внимания оставлять не следует.
Злоумышленники в нашем случае — это «школота», которая в летний период, вместо того, чтобы отдыхать и гулять, сливают в сети готовые разного рода программы и уже считают себя «хакерами». Смех да и только, но хлопот, те самые, запускаемые «школотой» программы доставляют не мало.
Прежде чем приступим к защите wp-login.php и wp-config.php, напомню несколько прошлых постов о защите сайтов на wordpress, которые актуальны и сейчас:
- Воспользуйтесь 5 практическими решениями для защиты сайта от взлома
- Делайте регулярный автоматический бекап данных в панели управления сервером ISP Manager
- Ну и прошлый пост о том, как мы можем закрыть доступ в админку сайта абсолютно всем и пофиг, что у них большой список прокси-серверов)
Отлично, идем дальше и закрываем от всех лишних глаз файл wp-login.php.
Шаг 1. Оригинальный wp-login.php переименуем в любое другое название, хоть в «s4gr3gerh6hb.php».
Шаг 2. Затем заменим все слова wp-login.php на новое имя, в нашем случае на s4gr3gerh6hb.php, в файле s4gr3gerh6hb.php (старый wp-login.php) и в файле wp-includes/general-template.php.
Шаг 3. Заключительным шагом станет полное ограничение доступа к файлу wp-login.php в .htaccess:
<Files wp-login.php>
Order Deny,Allow
Deny from all
</Files>
Поясню зачем ограничивать доступ к файлу wp-login.php, если по сути его уже нет, а есть новый, неизвестный злоумышленнику «s4gr3gerh6hb.php». Как я говорил выше, попытками взлома наших блогов занимаются далеко не серьезные люди, а «школота», которая скачивает программу-заготовку и запускает ее по инструкции, совершенно не соображая, что действия, производимые программой, бессмысленны.
Но нас на самом деле это не очень успокаивает, потому что в ответ на многочисленные запросы сервер возвращает нашу 404 страницу, а это очень большая нагрузка, которую мы можем избежать, воспользовавшись шагом 3. Теперь, когда в .htaccess к несуществующему файлу ограничен доступ, в ответ подлецу 🙂 будет отдаваться 403 ошибка, а серверу это какой либо заоблачной нагрузкой не грозит.
С защитой файла wp-config.php все намного проще. Нам он требуется крайне редко, если вообще после установки блога требуется, потому к нему достаточно закрыть доступ для всех. Пишем в .htaccess
<Files wp-config.php>
Order Deny,Allow
Deny from all
</Files>
и мы в шоколаде.
Удачи Вам, друзья, успехов. Предохраняйтесь, не давайте им шанса 😉
Изменил wp-login.php и general-template.php. Теперь при попытке ввода логина и пароля попадаю на 404 страницу, а не в админку
Что тут скажешь, видимо что-то упустили, еще раз просмотрите все внимательно.
Прошу прощения, дополнил пост, упустил один нюанс)
Вот теперь все работает. Спасибо Сергей!
С wp-login ничего не вышло, перестала грузится админка…
Проверял на wp разных версий. Вероятно что-то упускаете, внимательней еще раз пройдите по пунктам.
Здравствуйте, сергей. Хотела воспользоваться Вашим советом по защите сайта от взлома, но не нахожу у себя в файле wp-includes файл general-template.php. Он может как-то по другому именоваться? и второй вопрос в какое место нужно прописывать указанные вами коды для закрытия доступа в .htaccess — в конце или там где абзац для wordpress:
# BEGIN WordPress….
# END WordPress ?
Здравствуйте.
В папке wp-includes файл general-template.php.
Прописывать директивы можно в конце .htaccess файла.
А файл .htaccess для редактирования брать из корня сайта или из папки wp-admin ?
Тот, что в корне
Попробуйте так:
Сергей, спасибо за статью.
Возник вопрос: у меня второй шаг не понадобился » заменим все слова wp-login.php на новое имя», так как в этих файлах не было упоминания wp-login.php
но вроде все работает
это нормально?
Не уверен, может в какой-то версии во втором шаге нет необходимости. Если все работает корректно, значит порядок.
Отличный способ, но только для ботов. Так как если набрать /wp-admin редиректит к форме входа заодно и высвечивая в урл адрес измененного файла…
Как показывает опыт, обычно «заряжают» на конкретный файл, скажем у WP это wp-login.php, через папку попыток взлома еще не встречал.
Сейчас как раз идет на сервера FastVPS атака на wp-login.php
У многих серваки упали. Плагин с задачей не справился (Better WP Security)
А вот Ваш простой метод дал немедленный результат!
Очень рад, что помогло)
Сергей,огромное вам спасибо.Именно этот способ сработал на 200%.До этого что только не делала,а нагрузку от ботов не могла уменьшить(замучилась прописывать ip в .htaccess..).Нагрузка держалась 180-250ср,после закрытия папок сразу же упала до 14ср. !!!!!
Это здорово! Рад, что помогло.
А при обновлении wordpress не слетит ли?
Разумеется слетит). Статью в закладки и все в порядке;)
Что-то с .htaccess не так, он правило не выполняет.
Разумеется, цикл будет грузить.
Нет
Возможно, не могу знать, но если в .htaccess прописано правило на wp-login.php и оно не выполняется, значит что-то не так с .htaccess. Стоит в этой стороне все перепроверить.
Сергей, может есть какой-то способ закрыть доступ к wp-login.php через php, дописав что-то в этом файле? Чтобы при обращении к нему выдавалась 403 ошибка.
Я написал хостеру, чтобы он проверил htaccess, но тот уверяет, что он работает на 100%.
Единственное у меня с ним отличие в версии Apache. У меня на локальной машине – где всё работает как надо – версия 2.2.4, а у хостинга 2.4
Не знаю, что делать, менять из-за этого хостинг что-ли?
В противном случае брудфорс будет создавать нагрузку, а из-за неё меня хостер попросит сменить тариф на более дорогой, чего я делать не хочу.
Хотя, если блокировать командой PHP — это не блокировка на уровне сервера и она тоже будет вызывать нагрузку.
Я решил проверить работоспособность самой блокировки в htaccess и прописал следующее правило к другому файлу
Order deny,allow
deny from all
Выдаётся 404 ошибка без циклической переадресации как в случае с wp-login.php
Но ведь должна выдаваться 403 не так ли?
PS после file.php нет знака «=» (опечатка)
Можешь показать каким должен быть стандартный хтаксесс для Вордпрес?
Всё, проблема неактуальна, разобрался с ней вместе с хостингом.
Не успел ответить на предыдущие комментарии:). В чем проблема была?
Нужны было в htaccess прописать путь к собственной странице с 403 ошибкой, без этой строчки на локальной машине сайт работал нормально, а у хостинга шла циклическая переадресация.
Когда я прописал в htaccess свою 403 страницу, сайт заработал как надо.
Не думал, что проблема может быть в этом, но оказалось что так.
Странно как-то…вообще, по идее, у тебя не должно быть 403 страницы, она в принципе не нужна, если ты запрещаешь доступ к файлам сервера.
Ссори за оффтоп, но у тебя нет статьи о том, как сделать мобильную версию сайта на Вордпрес?
Плагин WPTouch не подходит, — он некорректно работает на всех темах Вордпреса. Нужно другое альтернативное решение адаптивнму дизайну.
Нет, такой нет(
Сергей,здравствуйте. Я тоже самое сделала на втором сайте.Все отлично работает.Еще раз спасибо. Но,видимо кто-то уже добрался до сайта,потому что плагин сообщает об изменениях файлов.В журнале вижу,что добавлены какие-то файлы с цифровыми наименованиями.Что делать? Как их найти и поудалять?Как почистить свою базу? Эти цифровые файлы прикреплены ,в основном,к картинкам и к page. Заранее спасибо.
Здравствуйте, Галина.
Очень жаль, но наверное не смогу Вам помочь. Попробуйте попросить помощи у хостинг-провайдера, думаю они могут прояснить откуда взялись эти файлы.
Разумеется. Ведь речь шла о защите от ботов. Как показывает опыт, обычно «заряжают» на конкретный файл, скажем у WP это wp-login.php, через папку попыток взлома еще не встречал. Можно полностью закрыть доступ в эту папку для не авторизованных пользователей (будет редиректить на главную сайта), а можно (и лучше) воспользоваться дополнительной защитой в виде htpasswd http://www.htaccesstools.com/htpasswd-generator/
Ну да, пока какой-либо гений не начнёт сливать идею трёх-семи, всё на порядок будет порядок. Фишки прекрасны, но в версии 3.6 подложили ещё ту хрюшку, умора в том, что это заслуга разрабов. Жжжуть а…
Если все раньше разом держали идею «беги с ucoz» то пришло время подумать совершить бегство и с этой ГС — CMS. ПрофПрограммер быстро обнаружит важность этих строк, например, новая фишка скрывать от яши, что блог не блог, дабы не убить п-тИЦ.
Кстати, disqus тоже дырявый =). ПС Google в помощь.
Что-то я не понимаю. Мы переименовали файл wp-login.php в другое название, но запрещаем дроступ в файле .htaccess не к новому файлу а к старому wp-login.php
Order Deny,Allow
Deny from all
Вот в первой строке прописан старый файл. Мы ведь старый wp-login.php переименовали, так зачем его запрещать, если его уже по сути не существует?
Все в порядке). Не успел ответить)
Отличное решение! Но столкнулся с тем, что не могу выйти из админки… При выходе вордпресс пытается найти файл wp-login.php, а он отсутствует и запрещен. Попытался поискать из какого файла ищется wp-login.php, но не смог найти. Не подскажите какой файл еще скорректировать?
В теме за это отвечают вот такие строчки:
<=a href="» title=»»>
(знак = везде в комментарии напихал, чтоб не искажало код)
Видимо поторопился с вопросом… Скорее всего это было из-за кэша Хрома. Стер его и вроде все нормально.
Рад, что все разрешилось)
Интересная мысль с переадресацией на википедию, спасибо)
Всем привет!
Спасибо за статью, а точнее за труд. Куда нам без Вас!
Но возникла проблемка. Сделал все как ту написано, на одном все без
проблем заходит и т.д, а вот на втором ресурсе, да выходит окно
автризации, ввожу данные и – No input file specified. C родными
файлами, все нормуль.
Скажите в чем проблема, всю голову сломал?! Движок WP 3.7.1
За ранее всем спасибо!
КА-РА-УЛ!!! Этот чудо способ, особенно для защиты от атак становится неудобным в связи с выходом версий 3.7 и тем более 3.8, где предусмотрено автообновление (не ручное, а действительно автоматическое без ведома админа)… Конечно, есть возможность запретить его, (очень хорошо описано на сайте Вэб-кошки), но теперь хочется автоматики…
Боюсь, автоматики в этом плане может и не быть…