Как запретить подбор имени пользователя в WordPress

Какой наиболее простой способ получить доступ к админке вашего сайта? Нет, не утюг или пытки :-)

Самый простой и эффективный способ — это подбор пароля к учётной записи.

Зная имя административной учётной записи вашего сайта (а чаще всего она называется admin), злоумышленник без особого труда запустит скрипт по перебору возможных паролей. Чаще всего это выполняется по словарю с паролями, который можно найти в интернете в свободном доступе.

Отсюда вытекает правило безопасности: не используйте пароли, типа 123456, qwerty и прочие простые фразы, которые в большинстве своём известны практически всем пользователям сети интернет.

Даже если ваш сайт никому не нужен (как чаще всего думают владельцы личных блогов), получив доступ к сайту, злоумышленник может изрядно подпортить вашу репутацию, либо начать зарабатывать деньги на вашем сайте.

Прямо сейчас измените административную учётную запись или смените пароль на существующую учётную запись

Сделали? Отлично! А теперь давайте запретим автоматический подбор имени пользователя, чтобы уж наверняка исключить ботам возможность в автоматическом режиме выуживать информацию с вашего сайта :-)

Зная логин вашей административной учётки — перебор пароля становится в разы эффективнее.

Примечание.
Если вы используете плагин Limit Login Attempt, либо Google Authenticator, то вы защищены очень хорошо. Эти плагины не позволяют совершать больше указанных попыток войти в административную панель, тем самым исключая перебор паролей.

Для использования блокировки доступа к страницам авторов на вашем сайте, воспользуйтесь следующим кодом:

RewriteEngine On
RewriteBase /
RewriteCond %{QUERY_STRING} (author=\d+) [NC]
RewriteRule .* - [F]

Скопируйте его и вставьте в файл .htaccess в корневой директории вашего сайта с WordPress.

Теперь при обращении на страницу http://адрес-вашего-сайта.ru/?author=1, злоумышленник будет получать 403 ошибку, что означает, что доступ запрещён. Таким образом исключается возможность подобрать логин учётной записи с правами администратора.

Рекомендую к прочтению:

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Комментарии

  • Спасибо за статью, очень полезно. У меня (версия WP 3.9) заработало вот в таком виде:
    «RewriteCond %{QUERY_STRING} (author) [NC]»

    P.S.
    Хотя мой сайт еще закрыт для индексации и нигде не «засвечен», уже который день идут попытки подбора доступа к админке :) Вывод: Limit Login Attempt — один из первоочередных плагинов для WP.

    • Да, Limit Login Attempts — хорошее решение для защиты от брутфорса :-)
      Понятно, что решение это не идеальное, но для начала — самое оно.

  • Не срабатывает. В моем файле в корневой была запись такого плана:

    # BEGIN WordPress

    RewriteEngine On
    RewriteBase /
    RewriteRule ^index.php$ — [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]

    # END WordPress

    Дописал во внутрь две строчки из вашего кода стало так:

    # BEGIN WordPress

    RewriteEngine On
    RewriteBase /

    RewriteCond %{QUERY_STRING} (author=d+) [NC]
    RewriteRule .* — [F]

    RewriteRule ^index.php$ — [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]

    # END WordPress

    И все равно заходит на страницу автора. Что не так?

    • Вот рабочий вариант конфига:
      <IfModule mod_rewrite.c>
      RewriteEngine On
      RewriteBase /
      RewriteCond %{QUERY_STRING} (author=d+) [NC]
      RewriteRule .* - [F]
      RewriteRule ^index.php$ - [L]
      RewriteCond %{REQUEST_FILENAME} !-f
      RewriteCond %{REQUEST_FILENAME} !-d
      RewriteRule . /index.php [L]
      </IfModule>

      Проверил сейчас на демонстрационном сайте — всё работает как часы.

      По какому пути заходите на страницу автора?
      Может у вас URL другие. И как версия WP?

      • Вы переписали то, что я написал выше. :)
        Версия 3.6
        Захожу через Вами указанный путь — http://адрес-сайта.com/?author=1 И спакойненько получаю страницу постов с логином в арессной строке

        • А давайте вместе посмотрим, чтоли :-)
          Отправьте мне на support@gruz0.ru реквизиты для доступа к FTP и адрес вашего сайта, я гляну, в чём может быть дело.

          Я изначально подумал, что дело в «равно» и кавычках, которые зачем-то подставил Disqus, поэтому попросту создал этот файл снова на демонстрационном сайте и добавил нужную строку.

          В результате:

      • Для интереса скопировал в файл то, что написали Вы. Результат тот же. Даже ради эксперимента удалил старый файл на сервере, чтоб исключить возможность не перезаписи. Поскольку на нем обычно стоят права доступа — 0644, что обычно не дает возможности его удолять и изменять.
        Результат — без изменений…

        • А у вас там точно Apache крутится, а не nginx? :-)
          В общем, было бы хорошо к FTP подключиться и посмотреть в живую, что там происходит такого специфического.

          • Я об этом подумал буквально после второго сообщения… Таки линуксовский буржуйский сервер. Но! Вот какая штука. Я файлы редактирую в Дримвивере и с WordPressОМ работая относительно недолго столкнулся с такой штукой, что очень часто при создании файла *.php важно все время следить за конфигурацией сохранения. Не только кодировка UTF — 8, но и Форма приведения к юникоду, которая бывает: C, D, KC, KD, должна быть отменена, то есть «нет» или «ноль», иначе части кода, функции и прочие мелочи могут не работать вообще. Как я с этим накалывался первое время!!! В Drupal, к примеру такого не встречал.
            Короче пересохранил я файл .htaccess и теперь он не выводит логин в адресной строке при адресе — http://адрес-сайта.com/?author=1 Но и на страницу 304 не перенаправляет. Я не знаю особенность ли это линуксовского сервера, но он в принципе не перенаправляет на страницу 403 при попытке получить доступ к страницам с ограниченным доступом или правами администратора, а просто отправляет на страницу ввода логина и пароля. При этом если ввести адрес несуществующей страницы, тут 404 срабатывает. У Вас случайно нет опыта работы с линуксовскими серверами? :)

            • Опыт-то есть, но тут дело не в операционной системе, а в настройках серверного ПО, веб-сервера в частности.

              304 — это совсем другой код ошибки, он нам ни к чему и никаким образом не должен проявиться.

              Предложенная в посте обработка .htaccess отвечает за отдачу 403 ошибки («Доступ запрещён»).

              А вообще, я рекомендую вам отказаться от Dreamweaver в пользу Notepad++, либо SublimeText 2. Именно в этих редакторах есть возможность выставить кодировку файла в UTF-8 Without BOM, которая как раз и нужна для нормальной работы.

            • Обработку 403/404 ошибок можно задать в этом же файле .htaccess директивой ErrorDocument, тогда все эти ошибки будут передаваться на какой-либо другой файл.

              В общем, нужно смотреть, что в вашем частном случае происходит :-)

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: