Настройка безопасных обновлений и установок для WordPress в Ubuntu
WordPress – одна из самых популярных систем управления контентом (CMS). В целом система WordPress является мощной, производительной и простой, но иногда пользователям приходится выбирать между удобством работы и безопасностью. К примеру, ущерб безопасности можно нанести при передаче прав и обновлении программ. Существует множество различных способов выполнить эти операции, среди которых есть и относительно безопасные способы обновления и установки тем и плагинов.
Требования
Для выполнения руководства нужен предварительно настроенный сервер Ubuntu; инструкции по начальной настройке можно найти в этой статье. Также нужно установить LAMP stack; подробная информация по установке этой группы программ – здесь.
Кроме того, нужно установить WordPress; для этого следуйте инструкциям этого руководства.
Настройка безопасных обновлений через SSH
Если на сервере не настроены обновления и установки на основе ключей, при попытке выполнить какую-либо из этих задач на экране появится запрос информации о подключении. Программа предложит предоставить учётные данные FTP: имя хоста, имя пользователя и пароль FTP.
По сути FTP является небезопасным протоколом, потому в большинстве случаев использовать его крайне не рекомендуется. Настройте установку для использования более безопасного протокола.
Изменение прав
Если вы следовали руководству по установке WordPress, предложенному в разделе Требования, вы передали права на каталог веб-сервера пользователю Apache. Это довольно распространённое действие при установке системы, однако оно может представлять угрозу безопасности. В идеале следует разделить владельца контента и процесс веб-сервера. Это нужно сделать, перед тем как разрешить обновления через SSH.
Создайте пользователя wp-user и передайте ему права на WordPress.
sudo adduser wp-user
Система предложит ответить на ряд вопросов и установить пароль. Пока что устанавливать пароль не нужно, потому просто нажмите Enter на все вопросы.
Перейдите в каталог /var/www/html, в котором хранятся файлы WordPress.
Передайте новому пользователю права на все файлы в этом каталоге, отняв эти права у пользователя www-data, предназначенного для Apache.
sudo chown -R wp-user:wp-user /var/www/html
SSH-ключи для WordPress
Теперь нужно создать пару SSH-ключей для пользователя WordPress. Войдите в систему как пользователь WordPress:
sudo su — wp-user
Чтобы создать пару ключей, используйте команду:
ssh-keygen -t rsa -b 4096
Программа спросит, где хранить ключи и как назвать их. Выберите каталог /home/wp-user/wp_rsa. Также программа предложит защитить ключи паролем. Чтобы пропустить это действие, просто нажмите Enter.
Вернитесь в учётную запись стандартного пользователя:
Чтобы защитить права, нужно сделать пользователя wp-user владельцем WordPress, а также передать права на WordPress группе www-data. Затем нужно запретить доступ к файлам для всех остальных пользователей.
sudo chown wp-user:www-data /home/wp-user/wp_rsa*
sudo chmod 0640 /home/wp-user/wp_rsa*
/.ssh и передайте ему соответствующие права:
sudo mkdir /home/wp-user/.ssh
sudo chown wp-user:wp-user /home/wp-user/.ssh/
sudo chmod 0700 /home/wp-user/.ssh/
Теперь введите открытый ключ в файл authorized_keys, чтобы пользователь мог входить при помощи этих учётных данных. Скопируйте открытый ключ:
sudo cp /home/wp-user/wp_rsa.pub /home/wp-user/.ssh/authorized_keys
Снова отредактируйте права на эти файлы, чтобы открыть к ним доступ, но оставить их защищёнными:
sudo chown wp-user:wp-user /home/wp-user/.ssh/authorized_keys
sudo chmod 0644 /home/wp-user/.ssh/authorized_keys
Так как эти ключи будут использоваться только для входа с сайта WordPress, который находится на этой же машине, можно ограничить доступ к этому серверу:
sudo nano /home/wp-user/.ssh/authorized_keys
В самом начале файла добавьте выделенную красным строку, которая разрешит доступ к ключам только локальной машине.
Сохраните и закройте файл.
Настройка WordPress для поддержки ключей
Теперь нужно установить пакеты, необходимые WordPress для поддержки авторизации на основе SSH.
sudo apt-get update
sudo apt-get install php5-dev libssh2-1-dev libssh2-php
Итак, теперь все утилиты установлены, отредактируйте конфигурационный файл.
sudo nano /var/www/html/wp-config.php
В конец файла добавьте код:
define(‘FTP_PUBKEY’,’/home/wp-user/wp_rsa.pub’);
define(‘FTP_PRIKEY’,’/home/wp-user/wp_rsa’);
define(‘FTP_USER’,’wp-user’);
define(‘FTP_PASS’,»);
define(‘FTP_HOST’,’127.0.0.1:22′);
Сохраните и закройте файл.
Перезапустите Apache, чтобы обновить настройки.
Тестирование результатов
Протестируйте настройки; для этого нужно войти на сайт WordPress как администратор:
Для проверки попробуйте установить новую тему. Кликните Appearance, а затем Themes. Нажмите Install Themes.
Выберите тему и кликните Install, чтобы установить её на сайт. WordPress должен успешно загрузить и установить пакет при помощи ключей.
Чтобы использовать новую тему, нажмите Activate. Чтобы просмотреть результаты, выберите visit site.
Общие проблемы
Во время настройки ключей SSH могут возникнуть некоторые проблемы.
Одна из распространенных ошибок может возникнуть при передаче изменений через веб-интерфейс:
Public and Private keys incorrect for user
Эта ошибка крайне неконкретна, она может быть вызвана множеством причин, вот некоторые из них:
Неправильные права на открытый ключ, закрытый ключ и каталоги, которые содержат их. Веб-сервер должен иметь возможность читать каждый из этих файлов; следовательно, если файлы принадлежат группе веб-сервера, то каждый файл должен иметь права 640.
С другой стороны, каталог
.ssh должен быть доступен только пользователю, который будет проходить авторизацию (например, wp-user). Содержимое каталога должно принадлежать этому пользователю и быть закрытым для изменения другими пользователями.
Неправильно установленный владелец файла. Эти ключи должны принадлежать определённым пользователям. Во время настройки пользователя и группы, которым принадлежат файлы, можно спутать пользователя WordPress и пользователя веб-сервера.
В данном примере оба ключа принадлежат пользователю wp-user и группе www-data. Это позволяет открыть веб-серверу доступ к файлам, но при этом передать их отдельному пользователю.
Неправильное форматирование файла. Если открытый или закрытый ключ содержит ошибки, WordPress откажется использовать его. То же самое касается файла
Ранее в файл authorized_keys была добавлена строка from=”127.0.0.1″ … Открытый ключ не должен содержать этой строки. Даже если SSH примет его как правильный файл, WordPress будет считать его недействительным и даже не станет отправлять его SSH-демону.
Следующая распространённая ошибка:
Could not create directory.
Как правило, эта ошибка связана с неправильно настроенным владельцем каталога. Чтобы обновлять файлы при помощи аккаунта wp-user, нужно предоставить этому пользователю все права доступа и собственности на каталоги загрузки.
Это значит, что все каталоги и файлы, хранящиеся в /var/www/html, нужно передать пользователю wp-user. Если вы следовали инструкциям этого руководства, но ошибка появилась, убедитесь, что команда chown была запущена с параметром –R.
Также нужно проверить, имеет ли пользователь WordPress права на запись в каталогах загрузки. Откройте document root:
Откройте права на каталоги; первый столбец содержит права на запись для владельца каталогов.
ls -l
total 180
-rw-r—r— 1 wp-user wp-user 177 Nov 18 15:21 index.html
-rw-r—r— 1 wp-user wp-user 418 Sep 24 20:18 index.php
-rw-r—r— 1 wp-user wp-user 20 Nov 18 15:24 info.php
-rw-r—r— 1 wp-user wp-user 19929 Jan 18 2013 license.txt
-rw-r—r— 1 wp-user wp-user 7128 Oct 23 16:08 readme.html
-rw-r—r— 1 wp-user wp-user 4892 Oct 4 10:12 wp-activate.php
drwxr-xr-x 9 wp-user wp-user 4096 Oct 29 16:08 wp-admin/
-rw-r—r— 1 wp-user wp-user 271 Jan 8 2012 wp-blog-header.php
-rw-r—r— 1 wp-user wp-user 4795 Sep 5 21:38 wp-comments-post.php
-rw-r—r— 1 wp-user wp-user 3350 Nov 19 12:23 wp-config.php
-rw-r—r— 1 wp-user wp-user 3177 Nov 1 2010 wp-config-sample.php
drwxr-xr-x 5 wp-user wp-user 4096 Nov 19 12:25 wp-content/
. . .
Как видите, права на файлы( -rw-r–r–) и каталоги (drwxr-xr-x) указывают, что владельцем является пользователь wp-user и только он имеет права на запись.
Выполните подобную проверку в каталоге wp-content, который хранит темы, плагины и т.п.
cd /var/www/html/wp-content
ls -l
total 16
-rw-r—r— 1 wp-user wp-user 28 Jan 8 2012 index.php
drwxr-xr-x 3 wp-user wp-user 4096 Oct 29 16:08 plugins
drwxr-xr-x 6 wp-user wp-user 4096 Nov 19 13:10 themes
drwxr-xr-x 2 wp-user wp-user 4096 Nov 19 13:10 upgrade
Как видите, каталоги настроены верно.
Заключение
Система управления контентом WordPress довольно проста в настройке и поддержке, однако иногда она подвергается опасности из-за простых настроек.
Рекомендуется вовремя устанавливать обновления, содержащие поправки и исправления безопасности системы. При этом не следует использовать небезопасные протоколы или права на каталоги.
Обеспечение безопасности процедуры обновления и правильная настройка прав на каталоги – довольно простой шаг, который может предотвратить серьёзную для сайта угрозу.
Источник
Как обновить WordPress: один из способов
Давеча, при реконструкции Блогосайта, возникла насущная необходимость обновить версию CMS, на которой он крутится — WordPress от 2.2.1 сразу до 3.8. Инструкций по этому вопросу можно найти без счёта — и у провайдеров, и просто в сети. Тем не менее, поскольку процедура эта прошла у меня легко и безболезненно, я решил составить ещё одну: во-первых, для себя, на будущее (чтобы ничего не забыть), во-вторых — для тех, кто пользуется CMS от хостера и проделывает эту операцию впервые.
Для начала — вводные данные. Я пользовался CMS, предоставляемой хостером, в момент создания Блогосайта, как уже сказано, это был WordPress версии 2.2.1. Необходимость апгрейда, кроме общих соображений (безопасность, идти в ногу со временем и прочие рассуждения в пользу бедных), была обусловлена настоятельной потребностью сменить тему оформления, старая перестала отвечать реалиям контента. А все подходящие для меня темы для моей версии WP просто отсутствовали. Как и многие весьма полезные плагины.
У меня на хостинге сосуществует около десятка сайтов — каждый в своём каталоге myname/$sitename . Корневым каталогом для WP каждого сайта является myname/$sitename/docs — у других провайдеров хостинга путь к корню может быть иным, например, $username/$sitename/wps/docs . Предполагается, что хостер предоставляет средства для управления файлами и СУБД через web-интерфейс (у меня — предоставляет).
Перво-наперво нужно разобраться с базой данных данного сайта — утрата сведений о ней может оказаться очень трудно восполнимой (а в некоторых случаях — и не восполнимой вообще, по крайней мере в полном объёме). В дальнейшем потребуются:
- её имя (при наличии нескольких проектов на одном хосте важно не ошибиться, какая база к какому сайту привязана);
- имя пользователя данной базы, который имеет право полного к ней доступа;
- пароль данного пользователя на доступ к базе;
- имя хоста базы данный — обычно это что-то вроде username_mysql .
Здесь надо помнить, что пользователь базы данных и администратор WP, это, подобно Марксу и Энгельсу, абсолютно разные лица аккаунты, и их учётные данные не имеют между собой ничего общего. Причём пользователей у одной базы может быть несколько, и не все они обладают совокупностью прав.
Все перечисленные сведения — абсолютно секретны, и ни в коем случае не должны стать достоянием врага (особенно врага Отечества). Поэтому они должны храниться в глубокой тайне, а получить их можно только путём сложных манипуляций через web-интерфейс к управлению СУБД хостера — обычно таковым является PHPMyAdmin. Однако страшную эту тайну раскрою — они могут быть содержатся и в файла wp-config.php , расположенном в корне сайта. Так что этот файл следует сохранить там, где он в ходе дальнейших действий будет под рукой.
Следующий шаг — архивирование собственно базы данных. Обычно хостер предоставляет такую услугу автоматически — но через определённые промежутки времени. Так что в данном случае нужно сделать снапшот актуального состояния базы. Для этого существует много инструментов — для моей старой версии я пользовался плагином к WP под названием WordPress Database Backup, но в новых версиях он вроде уже не поддерживается, так что надо подбирать подходящий (о плагинах будет отдельный разговор).
Затем я средствами хостерского файлового менеджера сделал zip-архив всего каталога с WP, начиная с корня (повторяю, у меня это $sitename/docs ) — на всякий пожарный случай, для восстановления первозданного вида. И отдельно, для упрощения дальнейших процедур, сделал также и zip-архивы подкаталога docs/wp-content/upload и его аналогов (в них помещаются закачанные на сайт файлы, например, иллюстрации к материалам, и тому подобное).
Все перечисленные архивы я скачал на локальную машину (разумеется, вместе с архивом базы), сохранив их в корневом каталоге сайта.
Дальнейшие рекомендации обычно сводятся к скачиванию последней версии WP (я скачивал последнюю русифицированную) в виде zip-архива и его распаковке в корневой каталог сайта: при этом все одноимённые файлы и подкаталоги старой версии должны быть заменены аналогами из версии новой.
В общем случае это, наверное, правильно — но у меня такой номер не прошёл: из архива WP распаковывались только отсутствующие файлы, а существующие сохранялись в неприкосновенности. Собственно, потому и потребовались предыдущие шаги по зазиплению подкаталогов.
Отступление. Скажу по секрету — прежде чем приступать к апгрейду движка Блогосайта, я воспользовался любезностью своего итальянского друга, сеньора Сьеро, и вдоволь потренировался на его сайте. Благо, и на нём я умудрился ничего не убить — просто отработал последовательность действий, показавшуюся мне оптимальной.
Так что я начал с того, что удалил всё содержимое каталога docs , кроме упомянутых ранее архивов — в хостерском файд-менеджере это сделать быстрее, чем выборочно сохранять заархивированные каталоги. А затем уже развернул архив WP. Далее можно поступить двояко.
Первый путь — просто загрузить в строке адреса http://URL-site/wp-admin/install.php и в нём вбить все сведения про базу данных, о которых говорилось ранее. Это, с одной стороны, легко. Но с другой — почему-то эти же данные сами собой прописались для некоторых (не всех!) других моих сайтов, в результате чего они стали загружать один и тот же контент — контент Блогосайта.
Вылечилось такое безобразие легко — правкой wp-config.php сайтов, им затронутых. Благо, сведения о базах данных я предусмотрительно сохранил для всех моих площадок на этом хосте. Но лучше, чтобы необходимости в лечении не возникало. Для чего достаточно скопировать файл wp-config-sample.php под именем wp-config.php и отредактировать последний руками. То есть заполнить в нём поля DB_NAME , DB_USER , DB_PASSWORD и DB_HOST значениями из старого, притыренного конфига. Сам wp-config-sample.php содержит исчерпывающие комментарии, из которых ясно, что именно в нём надо редактировать.
После этого и в этом случае надо загрузить install.php . Вопросов о базе данных теперь не возникнет, последует несколько предложений, со всеми из которых надо просто соглашаться. В том числе и с последним — загрузить ли обновлённый сайт. Ответом на что будет пустой экран. Что естественно, ведь в базе была прописана старая тема, нынче удалённая за ненадобностью.
Так что ничего страшного — достаточно зайти в админку WP по адресу http://URL-site/wp-admin/ и временно определить для сайта любую из трёх входящих в комплект тем. После чего заняться подбором темы идеальной. Но это уже сюжет одной из следующих историй. А пока остаётся только восстановить из архивов подкаталоги с картинками и прочими закачанными ранее файлами, и приступать к обустройству обновлённого сайта.
Применительно к Блогосайту обустройство я начал отнюдь не с подбора тем, а с установки жизненно важных плагинов, о чём расскажу на следующей странице.
Источник
