Как сделать процесс установки WordPress безопасным?

Дата публикации:Август 6, 2010

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

Начнем по порядку. Первое, что необходимо сделать, это добавить в файл header.php следующую строку:

<?php remove_action('wp_head', 'wp_generator'); ?>

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

Убедитесь также в том, что в файле wp-config.php присутствуют секретные ключи. Они сделают установку более безопасной. Сгенерировать четыре ключа можно по этой ссылке: api.wordpress.org/secret-key/1.1/. Подробнее об этом было сказано ранее.

Пользователи и пароли

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

Однако, это не гарантирует, что хакеры не смогут отыскать других пользователей с правами администратора. Если на вашем блоге присутствуют архивы пользователя, они могут вас выдать. Возможное решение — нигде не оставлять ссылок на авторский профиль (кроме тех, которые ведут за пределы WordPress), однако что делать, если без них никак не обойтись?

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

Значительно повышает безопасность сайта грамотно подобранный пароль — чем больше разнообразных символов он содержит, тем сложнее его взломать.

Работа с сервером

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

Некоторые специалисты WordPress советуют создавать дополнительные логины при помощи Apache и файла .htaccess. Более продвинутые решения предлагают различные плагины, описанные далее.

Первое, что требуется сделать, это проверить, присутствует ли пустой файл index.php или index.html в каждой папке сервера. Обычно этот файл создается в WordPress по умолчанию. Он блокирует непосредственный просмотр содержимого папок, что допускается некоторыми веб-хостингами. Если в какой-либо из папок он отсутствует, необходимо его создать.

Также можно подключить возможность SSL-шифрования, которое будет осуществляться при входе в панель администратора. Это осложнит потенциальным взломщикам задачу изучения исходящего трафика, возникающего в результате каких-либо действий администратора. Для того, чтобы включить SSL-шифрование, добавьте в wp-config.php следующую строку над комментарием «That’s all, stop editing! Happy blogging»:

define('FORCE_SSL_ADMIN', true);

SSL-шифрование может не работать, если ваш хостинг не поддерживает данную функцию. Некоторые хостинги предлагают данную услугу за определенную плату.

Поделиться

15 комментариев

  1. HotIce says:

    remove_action('wp_head', 'wp_generator');

    Хм. Я не большой спец по пхп, и вордпрессу, но у меня данный код прописан мало того что в функшн.пхп, так он к тому же, насколько я понимаю, является фильтром заглушкой для мета generator. Если его удалить, мета тег с версией как раз появится.На этом сайте светится, но думаю так и задумано..

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

    Интересно, откуда путаница ? И кто ее заказал ? ;) Забавно.

    Я сюда пришел с сайта, который ссылался сюда как источник статьи.

  2. Architect Of Ruin says:

    Да, вы правы, в этой статье присутствует ошибочная информация.

    Чтобы вручную удалить строку (к примеру) <meta name="generator" content="WordPress 2.9" />, необходимо не убрать инструкцию remove_action(‘wp_head’, ‘wp_generator’);, а, наоборот, добавить ее в файл header.php. Правда, вручную сейчас это мало кто делает, для этого уже давно изобрели специальные плагины, такие как Replace WP-Version, Secure WordPress и WP-Secure Remove WordPress Version.
    Радует, что остались еще внимательные читатели. Спасибо за помощь и актуальные правки! Эта статья будет доработана в кратчайшее время.

  3. HotIce says:

    Рад, что вам это не безразлично.
    Копипастеры.. если отбросить этику, они воруют время. Пока перелопатишь кучу перецитированного, с ума сойдешь. Надеюсь, тот на кого мы не ссылаемся поикает слегка. Я так понимаю, управы на него нет из-за ссылки.. Мдя.
    Что касается использования плагинов, то мои тараканы протестуют против их использования, но это вопрос пристрастий. Использую только те, работа которых для меня загадка, или код объемный.
    <<em>Остальная часть комментария помечена как личное>

  4. Architect Of Ruin says:

    Ссылка есть, значит вор — в законе :) Собственно, не только у меня берут, я заметил, но и с других источников. У меня яндекс склеил из-за этого некоторые страницы, то есть они в выдаче не отображаются, зато отображаются страницы того блога, который у меня их стащил с моими же статьями.

    Насчет плагинов: я считаю, что лучше использовать уже то, что существует, чем пытаться создать второе колесо. Намучался в свое время с самописными CMS, которые глючили на каждом шагу. Почему-то каждая новая компания хочет создать свою CMS (мы же крутые?! почему бы нет). Остается только спросить, зачем, когда вокруг необъятный горизонт проверенных решений.

    Насчет рубрики подумаю, давно хотел как-то это скомпоновать в удобоваримом виде. Здесь почти все — переводное, только с разных источников. А с постом что-нибудь придумаю — скорее всего, закрою)

  5. HotIce says:

    Так как я в деле блогинга новичок, то у меня брать нечего. Но читатель то я со стажем жыж..

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

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

    А что касается плагинов.. Я колесо не пытаюсь изобретать. Где я, и где вордпресс! ;) Упаси Бог. Сталкивался с плагинами, от которых мне нужна одна-две функции, и я не вижу смысла ради них держать файлы локализации интерфейса, систему актуализации версий плагина, и что они там еще делают.. Удобство использования, конечно, ниже, но меньше белых пятен в коде. Как то так. Но это мои тараканы, как я уже говорил. ;)

  6. Architect Of Ruin says:

    В таком подходе тоже есть один значительный недостаток. Представьте, прошло некоторое время, вы отвлеклись от работы (отпуск или еще что-то), а потом снова вернулись к блогу. Естественно, кое-что уже стало забываться, и вам пришла в голову мысль что-то поменять в коде. Заглядываем в код, а там вместо плагинов просто строки, раскиданные по разным пхп-файлам. Где, что, куда, кого менять? Это хорошо, если есть комментарии, а если их нет?

    Но тут опять же, кому как удобнее. Ваш способ, бесспорно, самый оптимальный, но требовательный к памяти)

  7. HotIce says:

    Конечно, способ своеобразный. Но я не оставляю файлы, все то, что мне надо живет в function.php, и с комментариями. Плагин установил, поковырял, и снес.. Просто админское прошлое приучило, потому как вы совершенно правы, через пол года я и свой то код с трудом прочитаю, а уж чужой да еще и пхп-шный.. Не, не, не.. Увольте. ;)

    Вот на счет памяти не понял что вы имеете в виду. Проверю. Когда пропускал много информации через себя по поводу движка, то почему-то отложилось, что плагины как раз и жрут эту самую память. Я же необходимые мне функции оттуда беру, изменяю, если что-то мне нужно, и в файл функций темы, и почему то считаю, что оттуда они дергаются только при прямом вызове в шаблоне. Если я ошибся, то это скверно, но не смертельно конечно.

  8. Architect Of Ruin says:

    Насчет памяти — я имел в виду человеческую память :)

  9. Леонид says:

    Скажите, пожалуйста, а эта статья, опубликованная в 2010 году, актуальна сегодня?

    • Дмитрий says:

      Здравствуйте, да, все актуально. Но тут приведен минимум. Были и другие статьи, посвященные защите. Посмотрите через поиск.

  10. Леонид says:

    Дмитрий, спасибо за ответ! Как правило, чтобы что-то найти на сайте, заходят на «Карту сайта», на которой в поисках других статей на тему безопасности сайта на WordPress я не нашёл таких важных: раздела, рубрики или категории, как «Безопасность сайта на WordPress» или «Защита сайта на WordPress», а ведь это — первое, что по рекомендациям некоторых специалистов надо изучать в начальной стадии создания сайта!
    К тому же общеизвестно, что, WordPress не безопасен своими «дырявыми» плагинами, например, Custom Content Type Manager, в котором только что обнаружили бэкдор, благодаря которому злоумышленник может похищать учётные данные пользователей зараженных сайтов, но, как утверждают спецы, тот же WordPress можно переписать чисто под свои нужды, и не накатывать дырявых плагинов!
    Что Вы можете сказать по этому поводу?

  11. Дмитрий says:

    Про основные найденные дыры в безопасности мы стараемся оперативно отписываться, чтобы пользователи могли предпринять защитные меры.

    • Леонид says:

      Дмитрий, а какое значение для поисковиков имеет «Карта сайта»?

      • Дмитрий says:

        Это аналог XML-карты сайта. Поисковой робот отслеживает материал по карте сайта. Соответственно, это повышает вероятность того, что робот проиндексирует больше разных статей.

Оставить комментарий

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

Получать новые комментарии по электронной почте. Вы можете подписаться без комментирования.

Предыдущая запись:

Следующая запись: