Пользователь
0,0
рейтинг
24 июня 2009 в 15:38

Разработка → 10 шагов для защиты вашего WordPress блога перевод

Административная зона любого веб-приложения давно стала излюбленной мишенью для хакеров и её безопасность чрезвычайно заботит разработчиков. Это касается и WordPress — при сустановке нового блога система создает аккаунт администратора с уникальным случайно сгенерированным в реальном времени паролем, чем блокирует всеобщий доступ к настройкам системы, контролируя его c помощью страницы авторизации.

Эта статья сфокусирована на вопросах усиления безопасности WordPress — как административной панели, так и настроек блога, подразумевая все содержимое папки «wp-admin», которое отображается только после авторизации. Мы сознательно выделили фразу "после авторизации" — вы должны четко осознавать, что только один простой запрос отделяет «злого хакера» и админку всего вашего блога или сайта! А последняя защищена настолько сильно, насколько мощный пароль вы выбрали.

gilt-zu-schuetzen-administrationsbereich-in-wordpress

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

1. Переименуйте папку wordpress.


Начиная с версии 2.6, стало возможным изменять путь к папке wp-content. К сожалению это до сих пор неприменимо к папке wp-admin. Думающие о безопасности блоггеры смирились с этим и стали надеяться, что это станет возможным в будущих версиях. Пока этого не случилось, предлагаем воспользоваться следующим альтернативным решением проблемы. После распаковки архива с файлами WordPress, вы увидите папку «WordPress» — переименуйте папку (в идеале во что-то непонятное вроде "wordpress_live_Ts6K") и после этого настройте соответственным образом файл wp-config.php, который находится в корневой директории.
Что нам даст это изменение?
  • Во-первых, все файлы WordPress не будут смешаны с другими файлами в корне сайта, таким образом мы повысим ясность корневого уровня.
  • Во-вторых, множество копий WordPress может быть установлено параллельно в папки с разными именами, исключая их взаимодействие, что делает это идеальным для тестирования
  • Третье преимущество напрямую касается безопасности: административная зона (и весь блог в целом) больше не находится в корневой папке и для проведения каких-либо действий по взлому сначала ее нужно будет найти. Это проблемно для людей, но что касается ботов — вопрос времени.

mehrere-installationen-in-einem-root-verzeichnis
Несколько установленных версий в root-каталоге — это возможно!

Примечание: Если системные файлы WordPress больше не в корневой директории, и имя папки инсталяции изменено в соответствии с рекомендациями, описанными выше, блог будет все равно доступен по адресу wp-config.ru. Почему? Зайдите в раздел «Общие настройки (General settings)» вашего блога и введите в поле «WordPress address (URL)» реальный адрес блога на сервере, как показано в примере:

wordpress_wordpress_address
Адрес блога должен быть красивым и ненавязчивым

Это позволит блогу отображаться по красивому виртуальному адресу.

2. Усовершенствуйте файл wp-config.php


Конфигурационный файл WordPress wp-config.php содержит в себе некоторые настройки сайта и информацию для доступа к базе данных. Также там другие настройки, касающиеся безопасности (они представлены в списке ниже). Если таких значений в этом файле нет, или же имеются только установленные по умолчанию, вам необходимо, соответственно, добавить или изменить их:
  • Ключи безопасности: начиная с версии 2.7, в WordPress есть четыре ключа безопасности, которые должны быть правильно установлены. WordPress спасает вас от необходимости выдумывать эти строки самому, автоматически генерируяправильные ключи с точки зрения безопасности. Вам просто нужно вставить ключи в соответствующие строки файла wp-config.php. Эти ключи являются обязательными для обеспечения безопасности вашего блога.
  • Префикс таблицы заново установленного WordPress блога не должен быть стандартным «wp_» Чем больее сложным будет значение префикса, тем менее вероятна возможность несанкционированного доступа к таблицам вашей MySQL базы данных. Плохо: $table_prefix = 'wp_';. Намного лучше: $table_prefix = 'wp4FZ52Y_'; Не стоит бояться забыть это значение — вам необходимо ввести его только один раз, больше оно вам не понадобится.
  • Если у вас на сервере доступно SSL шифрование, рекомендуется включить его для защиты административной зоны. Это можно сделать, добавив следующую команду в файл wp-config.php: define('FORCE_SSL_ADMIN', true);

Также вы можете регулировать другие системные настройки в конфигурационном файле. Четкий и исчерпывающий список доступных настроек доступен на странице Кодекса

wordpress_authentication_unique_keys
Не пренебрегайте установкой правильных ключей безопасности!

3. Переместите файл wp-config.php


Также начиная с версии 2.6, WordPress позволяет перемещать файл wp-config.php на высший уровень. По причине того, что этот файл содержит в себе намного более важную информацию, чем какой либо другой, и потому что всегда намного сложнее получить доступ к корневой папке сервера, имеет смысл хранить его не в той же директории, где и остальные файлы. WortdPress автоматически обратится к высшей папке в поиске файла wp-config.php. Любые попытки пользователей самим настроить путь бесполезны.

4. Защитите файл wp-config.php


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

[code]# protect wpconfig.php
<files wp-config.php>
Order deny,allow
deny from all

[/code]

Очень важно убедиться, что файл .htaccess находится в той же директории что и файл wp-config.php.

5. Удалите учетную запись администратора.


Во время процесса установки WordPress создает учетную запись администратора с ником «admin» по умолчанию. С одной стороны это вполне логично, с другой — пользователь с известным ником, т.е. ID — 1, обладающий административными правами, является вполне предсказуемой мишенью для хакеров с их программами подбора паролей. Отсюда следует наш совет:
  • Создайте еще одного пользователя с административными правами и вашим ником.
  • Завершите сеанс работы.
  • Залогиньтесь под новым аккаунтом.
  • Удалите учетную запись "admin".

Если у вас не новый блог и под учетной записью admin вы уже публиковали посты или комментарии, то из предложенных вариантов в момент удаления, выберите пункт «Связать все записи и ссылки с:» и выберите имя нового пользователя:

wordpress_delete_user

Примечание: В идеале желательно чтобы логин нового пользователя отличался от отображаемого имени пользователя в постах, чтобы никто не узнал ваш логин.

6. Выберите сильный пароль.


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

Чаще всего именно пароли являются самым слабым звеном в этой цепи. Почему? Способы выбора пароля у большинства пользователей зачастую необдуманны и беспечны. Многие проведенные исследования показали, что большинство паролей — односложные существующие слова, набранные строчными буквами, которые не сложно подобрать. В программах подбора паролей существуют даже списки самых часто используемых паролей.

В WordPress реализован интуитивно понятный индикатор стойкости набираемого пароля, который показывает цветом его уровень сложности:

wordpress_passwort_staerke

Мы рекомендуем использовать как минимум семь символов, комбинировать строчные и прописные и использовать служебные символы такие как! "? $ % ^ & ( ).

7. Защитите папку «wp-admin».


Следуя пословице «две головы лучше одной», существует способ вдвое усилить защиту административной зоны. Защита регулируется файлом .htaccess, который должен находится в папке «wp-admin» вместе с файлом .htpasswd, который хранит логин и пароль пользователя. После обращения к папке, вам нужно будет ввести логин и пароль, но разница в том, что в этом случае авторизация контролируется на стороне сервера, а не силами самого WordPress.

Для того чтобы просто и быстро сгенерировать файлы .htaccess и .htpasswd, воспользуйтесь этим сервисом.

8. Запретите отображение ошибок на странице авторизации.


Страница авторизации WordPress — это дверь в административную зону вашего блога, которая становится доступна после безошибочного прохождения верификации. У каждого пользователя существует бесконечное количество попыток авторизации, и каждый раз по умолчанию услужливый WordPress указывает, в чем именно была ошибка. То есть, если введенный логин окажется неверным — WordPress так и скажет. Это удобно для пользователя, но также и для хакера.

Несложно догадаться, как быстро сокращается вероятность подбора комбинации логина/пароля, когда система указывает что именно введено неверно. Простая строка кода, поможет решить эту проблему, достаточно добавить её в файл functions.php вашей темы:

[php]add_filter('login_errors',create_function('$a', «return null;»));[/php]
wordpress_login_screen
Изначальный/измененный вид страницы авторизации.

9. Ограничьте количество неудачных попыток авторизации.


WordPress не ведет статистику авторизаций, как удачных, так и нет. Это очень неудобно для администратора, так как у него нет возможности увидеть были ли попытки несанкционированного доступа, чтобы принять какие-либо меры, если они участятся. Предлагаем два решения: плагины Login LockDown и Limit Login Attempts. После установки они не только ведут лог авторизаций, но также ограничивают количество неудавшихся попыток авторизации, блокируя на определенное время IP пытающегося.

wordpress_login_lockdown

10. Поддерживайте актуальные версии.


И последнее: как правило разработчики WordPress очень быстро реагируют, если находят уязвимости в движке. Поэтому следите за обновлениями и обновляйтесь, когда возможно. Благо сам WordPress оповещает о выходе новой версии. Это касается и плагинов — держите их версии актуальными.

wordpress_plugin_verwaltung

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

А вы?


Как вы защищаете свой блог от взлома? Что используете для этого?

Перевод с сайта WordPress для каждого!
Перевод: SmashingMagazine
Дмитрий Чебаков @codepoet
карма
35,5
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (51)

  • +2
    Некоторые способы достаточно изощренные, но должны пойти на пользу.
  • +1
    Некоторые способы могут показаться параноидальными, но как программист могу сказать, это то, что действительно может защитить ваш блог от взлома.
    • НЛО прилетело и опубликовало эту надпись здесь
  • +1
    про ssl хорошо, не знал
  • +2
    1. С большой долей вероятности отпадет часть плагинов, т.к. частенько хардкодят путь к wp-content (тоже относится к 2.2)
    10. Никто не застрахован от взлома кривых плагинов, более страшный вариант — кто-то ломанет доступ девелопера к SVN и зальет «обновления»
    • 0
      1. wp-content относительно внутренней структуры останется неизменным, а в пенкте 2 нужно изменить файл wp-config.php, который не касается папки «wp-content».
      10. поэтому и рекомендуется устанавливать только нужные и проверенные.
      • +1
        Даже у проверенных плагинов есть авторы — а у них есть доступ к SVN'у…
    • НЛО прилетело и опубликовало эту надпись здесь
  • –2
    Лучше создать блог «Я параноик» и публиковать это туда :D
    • +5
      не стоит путать параною и беспечность ;-)
  • +2
    Большая часть советов, увы, относится к категории "Security through obscurity" и является примером неправильного подхода к усилению безопасности.

    К использованию можно рекомендовать только пункты 6, 9 и 10, которые трудно назвать оригинальными, не правда ли?
    • 0
      что на счет 2 пункта? думаете стоит паренебрегать правильной(рекоммендуемой разработчиками) настройкой установочных файлов? а поверьте многие даже не подозревают что там есть такие поля…
      • 0
        установочных=конфигурационных
      • +1
        Рекомендованные разработчиками настройки не обязаны являться правильными. JFYI.

        С советом включить SSL я согласен.

        Совет менять префикс имени таблицы — классический пример STO. Самообман, ведущий к ощущению безопасности.

        Что же до генерации уникальных ключей, то это должно защитить от чего конкретно? Вопрос без подвоха: я незнаком с исходниками последних версий wp.
        • 0
          Соглашусь, что возможно вы правы и не все советы из списка значительно увеличивают безопасность. Но не соглашусь что всех их стоит списывать со счетов.

          Что же до генерации уникальных ключей, то они должны усиливать шифрование информации в пользовательских кукисах, особенно для пользователей с привилегиями администратора и модератора. И чем-то еще. Подробности нужно смотреть в документации.
          • 0
            Я кратко просмотрел исходники. Я вижу, что эти ключи помогают в случае, если кто-то УЖЕ хакнул сайт и вынес базу с хэшами паролей.
        • 0
          Ээээ. Какой еще самообман? Нестандартные имена вполне себе могут спасти, если обнаружена sql инъекция для которой разработчиками еще не выпущен хотфикс.
          • 0
            Спасибо, Вы привели хороший пример ложной уверенности. Практически все промышленные СУБД предоставляют средства доступа к метаданным. Соответственно, при наличии sql injection нет ничего катастрофически сложного в том, чтобы получить доступ к таблице, зная не ее полное имя, а только уникальный постфикс. Сложность и осуществимость зависят, разумеется, от характера sql injection.

            У примеру, в MySQL можно начать с протаскивания примерно такого запроса:

            select * from information_schema.tables where table_name like '%users'


            Соответственно, человек, сменив префикс на уникальный, ощущает ложную безопасность и не будет так спешить ставить фикс.

            Спасибо за пример.
            • 0
              Я в курсе. А вот пишущие и читающие журнал «Хакер» судя по тем статьям что когда-то попадались на глаза — нет. Задача сунуть палки в колеса как можно бОльшему количеству людей. Если есть вероятность что кто-то может не знать такой конструкции — почему бы не усложнить ему жизнь?
              • 0
                Эта задача прежде всего превращается в «сунуть палки в колёса себе» :)
  • НЛО прилетело и опубликовало эту надпись здесь
  • НЛО прилетело и опубликовало эту надпись здесь
    • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    *** К сожалению это до сих пор неприменимо к папке wp-admin.

    Ну почему же? Если покопаться… ну, а если не копаться, то «Заменить» во всех файлах и все.
  • 0
    если Вордпресс уже стоит есть ли возможность поменять префикс таблиц?
    • 0
      Да, если у вас есть доступ к редактированию конфигурационного файла. На самом деле, кстати, в базе может храниться несколько вордпресовских баз с разными префиксами.
  • НЛО прилетело и опубликовало эту надпись здесь
  • –1
    а нет такого же руководства для joomla? или там все сложнее?
  • 0
    Насчёт префикса таблиц замечу, что если поставить свой некоторые плагины не работают или тема у меня одна падала от этого
    • +1
      Использовал нестандартные префиксы таблиц неодногократно, все работало как надо. Плагины которые от изменения префикса таблиц перестают работать это быдло-плагины какие то :)
  • 0
    Статья, на мой лично взгляд, тупейший бред для ламеров. Например, пункт 4 — кто-нибудь внятно способен объяснить, для чего это может быть нужно? Если файл wp-config.php находится в одном каталоге с index.php, само собой разумеется, что при обращении к нему «извне» (#$%) он будет обработан mod_php, и содержимое открыто не будет. Какой черт добавлять в .htaccess _лишнюю_ конфигурационную строку?

    Советы 6 и 10 вообще очевиднее не придумаешь.

    Такое чувство, что вы перевели статью, которую кто-то написал просто чтобы «добить» место на страницах журнала.
  • +4
    А вы? Как вы защищаете свой блог от взлома? Что используете для этого?
    1. Фильтрация XSS (отдельная статья страниц на 5)
    2. No direct access alowed (index.html)
    3. No direct script access allowed (проверка переменной под дефайном)
    4. mysqlrealescapestring
    5. intval($page), substr($string,0,255)
    6. NO GET
    7. htmlspechialchars
    8. Disable CGI|PHP для расшаренных папок(картинки и т.п.), субдомены
    9. encrypt_cookie
    10. Валидация кук с сессиями
    Это если вкратце.
    • +1
      Если тоже самое подробнее — получится отличный пост!
      • 0
        то же самое подробнее:
        recoilme.ru/blog/comments/237
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      хабр исправляет кавычки на свои
  • +2
    А ограничение по диапазонам IP своего провайдера и мест использования — 99.99% защита
    Остальной 0.01% приходится на случаи если взломщик в одной подсети
    • 0
      Замечательное решение! Сам удивился, что его нет в оригинальной статье, но дописавать от себя не стал, ограничился переводом.
      P.S. Способ будет затруднителен, если вы делаете не для себя, а для заказчика например.
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Ага :) Залезть по ФТП :)
      • 0
        для этого нужны пути отступления — провайдер родителей, адреса соседнего интернет-кафе. Поэтому я и сделал приписку — «и мест использования»
  • +2
    Паролить wp_admin через браузер не рекоммендую, ибо тогда флеш-аплодер требует авторизацию отдельно, при этом первая картинка в любом случае не обрабатывается → получается пустой.
    • 0
      не знал этого, спасибо за совет
  • НЛО прилетело и опубликовало эту надпись здесь
  • +1
    Рекомендую также удалять лишние файлы. Например, readme.html в корневой папке движка.

    В одной из подобных статей (а возможно даже в комментариях к копиям этой же статьи на иных сайтах) активно рекомендовали скрывать отображение текущей версии движка. В том числе через плагины типа Replace WP-Version (http://wordpress.org/extend/plugins/replace-wp-version/). Мера конечно сомнительная, но допустим, что её можно тоже применить, как дополнение.

    НО, нет смысла прятать демонстрацию версии WP, если можно обратиться к readme.html и получить эти данные:

    www.vanilla-man.com/readme.html
    wp-config.ru/readme.html

    Этот файл вновь будет появляться всякий раз, как мы будем обновлять версию WP в авторежиме.
    • +1
      я не прятал её и в коде, так как не вижу в этом смысла… соответственно readme.html тоже оставлял
      но если вы таки решились на этот шаг — особенно странно убирать всего одну строку в теме при помощи плагина
      • 0
        У себя я версию не скрывал — не вижу особого смысла.
  • 0
    А кто как борется со спамом в комментариях? Как можно добавить дополнительные поля в форму для комментария? Может есть такие плагины? Посоветуйте пожалуйста! Спасибо!
    • 0
      • 0
        Спасибо Вам за помощь! Никак не могу найти решение/плагин для добавления своих полей в форму для комментария… Может кто уже решил эту проблему? Спасибо!
  • 0
    В общем, советы по защиет одни и те же, только теперь вам стоит немного потратиться на человека, который за деньги проверит ваш сайт на наличие уязвимостей и сообщит вам результаты.

    Хочу предложить Вам в помощь сайт hackmysite.ru для проверки защиты вашего ресурса — по сути фриланс биржа для людей обладающих умением взлома. От вас требуется разместить проект, указать тип уязвимости и бюджет. Дальше просто — ждать предложения выполнить проект от экспертов взлома. Проект молодой и ждёт своих клиентов!

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.