Еще пара уловок для защиты блога на wordpress

В нарушение всех планов на написание постов хочу дополнить предыдущий пост о защите блога на wordpress, а точнее о защите файлов и папок средствами .htaccess. В корне наших блогов лежат файлы wp-login.php и wp-config.php, которые особенно интересны злоумышленнику, ну и нам их без внимания оставлять не следует.

Злоумышленники в нашем случае — это «школота», которая в летний период, вместо того, чтобы отдыхать и гулять, сливают в сети готовые разного рода программы и уже считают себя «хакерами». Смех да и только, но хлопот, те самые, запускаемые «школотой» программы доставляют не мало.

Защита файлов wp-login.php и wp-config.php от взлома

Прежде чем приступим к защите wp-login.php и wp-config.php, напомню несколько прошлых постов о защите сайтов на wordpress, которые актуальны и сейчас:

Отлично, идем дальше и закрываем от всех лишних глаз файл 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>

и мы в шоколаде.

Удачи Вам, друзья, успехов. Предохраняйтесь, не давайте им шанса 😉


Комментарии

59 на запись "Еще пара уловок для защиты блога на wordpress"
  1. Изменил wp-login.php и general-template.php. Теперь при попытке ввода логина и пароля попадаю на 404 страницу, а не в админку

  2. Дмитрий says:

    С wp-login ничего не вышло, перестала грузится админка…

  3. Евгения says:

    Здравствуйте, сергей. Хотела воспользоваться Вашим советом по защите сайта от взлома, но не нахожу у себя в файле wp-includes файл general-template.php. Он может как-то по другому именоваться? и второй вопрос в какое место нужно прописывать указанные вами коды для закрытия доступа в .htaccess — в конце или там где абзац для wordpress:
    # BEGIN WordPress….
    # END WordPress ?

  4. Юрий says:

    А файл .htaccess для редактирования брать из корня сайта или из папки wp-admin ?

  5. alvarvas says:

    Сергей, спасибо за статью.

    Возник вопрос: у меня второй шаг не понадобился » заменим все слова wp-login.php на новое имя», так как в этих файлах не было упоминания wp-login.php
    но вроде все работает
    это нормально?

  6. Борис says:

    Отличный способ, но только для ботов. Так как если набрать /wp-admin редиректит к форме входа заодно и высвечивая в урл адрес измененного файла…

  7. Галина says:

    Сергей,огромное вам спасибо.Именно этот способ сработал на 200%.До этого что только не делала,а нагрузку от ботов не могла уменьшить(замучилась прописывать ip в .htaccess..).Нагрузка держалась 180-250ср,после закрытия папок сразу же упала до 14ср. !!!!!

  8. alex says:

    А при обновлении wordpress не слетит ли?

  9. Что-то с .htaccess не так, он правило не выполняет.

  10. Разумеется, цикл будет грузить.

  11. Возможно, не могу знать, но если в .htaccess прописано правило на wp-login.php и оно не выполняется, значит что-то не так с .htaccess. Стоит в этой стороне все перепроверить.

  12. Serg says:

    Сергей, может есть какой-то способ закрыть доступ к wp-login.php через php, дописав что-то в этом файле? Чтобы при обращении к нему выдавалась 403 ошибка.

    Я написал хостеру, чтобы он проверил htaccess, но тот уверяет, что он работает на 100%.

    Единственное у меня с ним отличие в версии Apache. У меня на локальной машине – где всё работает как надо – версия 2.2.4, а у хостинга 2.4

    Не знаю, что делать, менять из-за этого хостинг что-ли?

    В противном случае брудфорс будет создавать нагрузку, а из-за неё меня хостер попросит сменить тариф на более дорогой, чего я делать не хочу.

  13. Serg says:

    Хотя, если блокировать командой PHP — это не блокировка на уровне сервера и она тоже будет вызывать нагрузку.

  14. Serg says:

    Я решил проверить работоспособность самой блокировки в htaccess и прописал следующее правило к другому файлу

    Order deny,allow
    deny from all

    Выдаётся 404 ошибка без циклической переадресации как в случае с wp-login.php
    Но ведь должна выдаваться 403 не так ли?

  15. Serg says:

    PS после file.php нет знака «=» (опечатка)

  16. Serg says:

    Можешь показать каким должен быть стандартный хтаксесс для Вордпрес?

  17. Serg says:

    Всё, проблема неактуальна, разобрался с ней вместе с хостингом.

    • Не успел ответить на предыдущие комментарии:). В чем проблема была?

      • Serg says:

        Нужны было в htaccess прописать путь к собственной странице с 403 ошибкой, без этой строчки на локальной машине сайт работал нормально, а у хостинга шла циклическая переадресация.

        Когда я прописал в htaccess свою 403 страницу, сайт заработал как надо.
        Не думал, что проблема может быть в этом, но оказалось что так.

      • Serg says:

        Ссори за оффтоп, но у тебя нет статьи о том, как сделать мобильную версию сайта на Вордпрес?

        Плагин WPTouch не подходит, — он некорректно работает на всех темах Вордпреса. Нужно другое альтернативное решение адаптивнму дизайну.

  18. Галина says:

    Сергей,здравствуйте. Я тоже самое сделала на втором сайте.Все отлично работает.Еще раз спасибо. Но,видимо кто-то уже добрался до сайта,потому что плагин сообщает об изменениях файлов.В журнале вижу,что добавлены какие-то файлы с цифровыми наименованиями.Что делать? Как их найти и поудалять?Как почистить свою базу? Эти цифровые файлы прикреплены ,в основном,к картинкам и к page. Заранее спасибо.

    • Здравствуйте, Галина.
      Очень жаль, но наверное не смогу Вам помочь. Попробуйте попросить помощи у хостинг-провайдера, думаю они могут прояснить откуда взялись эти файлы.

  19. Разумеется. Ведь речь шла о защите от ботов. Как показывает опыт, обычно «заряжают» на конкретный файл, скажем у WP это wp-login.php, через папку попыток взлома еще не встречал. Можно полностью закрыть доступ в эту папку для не авторизованных пользователей (будет редиректить на главную сайта), а можно (и лучше) воспользоваться дополнительной защитой в виде htpasswd http://www.htaccesstools.com/htpasswd-generator/

  20. Даниил Сосновский(программер) says:

    Ну да, пока какой-либо гений не начнёт сливать идею трёх-семи, всё на порядок будет порядок. Фишки прекрасны, но в версии 3.6 подложили ещё ту хрюшку, умора в том, что это заслуга разрабов. Жжжуть а…

    Если все раньше разом держали идею «беги с ucoz» то пришло время подумать совершить бегство и с этой ГС — CMS. ПрофПрограммер быстро обнаружит важность этих строк, например, новая фишка скрывать от яши, что блог не блог, дабы не убить п-тИЦ.

    Кстати, disqus тоже дырявый =). ПС Google в помощь.

  21. Юрий says:

    Что-то я не понимаю. Мы переименовали файл wp-login.php в другое название, но запрещаем дроступ в файле .htaccess не к новому файлу а к старому wp-login.php

    Order Deny,Allow
    Deny from all

    Вот в первой строке прописан старый файл. Мы ведь старый wp-login.php переименовали, так зачем его запрещать, если его уже по сути не существует?

  22. Все в порядке). Не успел ответить)

  23. Борис says:

    Отличное решение! Но столкнулся с тем, что не могу выйти из админки… При выходе вордпресс пытается найти файл wp-login.php, а он отсутствует и запрещен. Попытался поискать из какого файла ищется wp-login.php, но не смог найти. Не подскажите какой файл еще скорректировать?

  24. Борис says:

    В теме за это отвечают вот такие строчки:

    <=a href="» title=»»>

    (знак = везде в комментарии напихал, чтоб не искажало код)

  25. Борис says:

    Видимо поторопился с вопросом… Скорее всего это было из-за кэша Хрома. Стер его и вроде все нормально.

  26. Интересная мысль с переадресацией на википедию, спасибо)

  27. Сергей says:

    Всем привет!

    Спасибо за статью, а точнее за труд. Куда нам без Вас!

    Но возникла проблемка. Сделал все как ту написано, на одном все без
    проблем заходит и т.д, а вот на втором ресурсе, да выходит окно
    автризации, ввожу данные и – No input file specified. C родными
    файлами, все нормуль.

    Скажите в чем проблема, всю голову сломал?! Движок WP 3.7.1
    За ранее всем спасибо!

  28. Борис says:

    КА-РА-УЛ!!! Этот чудо способ, особенно для защиты от атак становится неудобным в связи с выходом версий 3.7 и тем более 3.8, где предусмотрено автообновление (не ручное, а действительно автоматическое без ведома админа)… Конечно, есть возможность запретить его, (очень хорошо описано на сайте Вэб-кошки), но теперь хочется автоматики…

Спасибо, что оставили свой комментарий

banner