Я просмотрел здесь, но не нашел подробностей о лучших разрешениях для файлов. Я также взглянул на некоторые вопросы формы WordPress по поводу и здесь, но всем, кто предлагает 777, явно нужен небольшой урок по безопасности.
Короче мой вопрос такой. Какие разрешения я должен иметь для следующего:
а потом все файлы в каждой из этих папок?
При настройке WP вам (веб-серверу) может потребоваться доступ на запись к файлам. Таким образом, права доступа могут быть потеряны.
chown www-data:www-data -R * # Let Apache be owner
find . -type d -exec chmod 755 {} \; # Change directory permissions rwxr-xr-x
find . -type f -exec chmod 644 {} \; # Change file permissions rw-r--r--
После настройки вы должны ограничить права доступа, в соответствии с усилением WordPress все файлы, кроме wp-контента, должны быть доступны для записи только вашей учетной записи пользователя. wp-контент должен быть доступен для записи и для www-данных.
chown <username>:<username> -R * # Let your useraccount be owner
chown www-data:www-data wp-content # Let apache be owner of wp-content
Возможно, вы захотите изменить содержимое wp-содержимого позже. В этом случае вы могли бы
su,Что бы вы ни делали, убедитесь, что файлы имеют права доступа rw для www-данных.
Предоставление полного доступа ко всем файлам wp пользователю www-data (который в этом случае является пользователем веб-сервера) может быть опасным.
Поэтому не делайте этого:
chown www-data:www-data -R *
Это может быть полезно, однако, в тот момент, когда вы устанавливаете или обновляете WordPress и его плагины. Но когда вы закончили, уже не рекомендуется хранить файлы wp, принадлежащие веб-серверу.
В основном это позволяет веб-серверу помещать или перезаписывать любой файл на вашем веб-сайте. Это означает, что есть возможность взять ваш сайт, если кому-то удастся использовать веб-сервер (или отверстие безопасности в некотором .php script), чтобы поместить некоторые файлы на ваш сайт.
Чтобы защитить свой сайт от такой атаки, вы должны:
Все файлы должны принадлежать вашей учетной записи пользователя и должны быть доступны для записи тобой. Любой файл, который требует доступа на запись из WordPress, должен быть доступный для записи на веб-сервере, если это требует ваш хостинг, это может означать, что эти файлы должны принадлежать группе из используемой учетной записи пользователя с помощью процесса веб-сервера.
/Корневой каталог WordPress: все файлы должны быть доступны для записи только вашей учетной записью пользователя, кроме .htaccess, если вы хотите, чтобы WordPress автоматически генерируйте правила перезаписи для вас.
/wp-admin/Область администрирования WordPress: все файлы должны быть доступны для записи только вашей учетной записью пользователя.
/wp-includes/Основная часть логики приложения WordPress: все файлы должны быть доступны для записи только вашей учетной записью пользователя.
/wp-content/Содержимое, поставляемое пользователем: предназначено для записи в учетной записи пользователя и процесса веб-сервера.
Внутри
/wp-content/вы найдете:
/wp-content/themes/Файлы тем. Если вы хотите использовать встроенный редактор тем, все файлы должны быть доступны для записи в процессе веб-сервера. Если ты не хотите использовать встроенный редактор тем, все файлы могут быть доступны только для записи по вашей учетной записи пользователя.
/wp-content/plugins/Файлы плагинов: все файлы должны быть доступны для записи только вашей учетной записью пользователя.
Другие каталоги, которые могут присутствовать с
/wp-content/, должны быть задокументированный любым плагином или темой. Разрешения могут изменяются.
Источник и дополнительная информация: http://codex.wordpress.org/Hardening_WordPress
Для тех, у кого есть корневая папка wordpress под их домашней папкой:
** Ubuntu/apache
CREDIT Предоставление разрешений на запись в группу www-data
Вы хотите вызвать usermod для своего пользователя. Итак, это будет:
sudo usermod -aG www-data yourUserName
** Предполагая, что существует группа www-data
Проверьте, что ваш пользователь находится в группе www-data:
groups yourUserName
Вы должны получить что-то вроде:
youUserName : youUserGroupName www-data
** youUserGroupName обычно похож на ваше имя пользователя
Рекурсивно изменить групповое владение папкой wp-content, сохраняя право пользователя на
chown yourUserName:www-data -R youWebSiteFolder/wp-content/*
Измените каталог на youWebSiteFolder/wp-content/
cd youWebSiteFolder/wp-content
Рекурсивно изменить групповые разрешения папок и подпапок, чтобы разрешить права на запись:
find . -type d -exec chmod -R 775 {} \;
** режим `/home/yourUserName/youWebSiteFolder/wp-content/'изменен с 0755 (rwxr-xr-x) на 0775 (rwxrwxr-x)
Рекурсивно изменить групповые разрешения файлов и подфайлов, чтобы разрешить права на запись:
find . -type f -exec chmod -R 664 {} \;
Результат должен выглядеть примерно так:
WAS:
-rw-r--r-- 1 yourUserName www-data 7192 Oct 4 00:03 filename.html
CHANGED TO:
-rw-rw-r-- 1 yourUserName www-data 7192 Oct 4 00:03 filename.html
Эквивалент:
chmod -R ug + rw имя папки
Разрешения будут похожи на 664 для файлов или 775 для каталогов.
P.s. если кто-то сталкивается с ошибкой 'could not create directory' при обновлении плагина, выполните: [email protected]:~/domainame.com$ sudo chown username:www-data -R wp-content
когда вы находитесь в корне вашего домена.
Предполагая: wp-config.php имеет
Учетные данные FTP на LocalHost define('FS_METHOD','direct');
Лучше всего прочитать документацию Wordpress на этом https://codex.wordpress.org/Changing_File_Permissions
- Все файлы должны принадлежать фактической учетной записи пользователя, а не учетной записи пользователя, используемой для процесса httpd.
- Групповое владение не имеет значения, если только не требуются конкретные групповые требования для проверки прав доступа к веб-серверу. Обычно это не так.
- Все каталоги должны быть 755 или 750.
- Все файлы должны быть 644 или 640. Исключение: wp-config.php должно быть 440 или 400, чтобы другие пользователи на нем не читали его.
- Никакие каталоги никогда не должны предоставляться 777, даже загружать каталоги. Поскольку процесс php работает как владелец файлов, он получает разрешения владельцев и может писать даже в каталог 755.
Я установил права на:
# Set all files and directories user and group to wp-user
chown wp-user:wp-user -R *
# Set uploads folder user and group to www-data
chown www-data:www-data -R wp-content/uploads/
# Set all directories permissions to 755
find . -type d -exec chmod 755 {} \;
# Set all files permissions to 644
find . -type f -exec chmod 644 {} \;
В моем случае я создал отдельного пользователя для WordPress, который отличается от пользователя по умолчанию apache, который запрещает доступ из Интернета к файлам, принадлежащим этому пользователю.
Затем он дает разрешение пользователю apache на обработку папки загрузки и, наконец, устанавливает достаточно безопасные разрешения для файлов и папок.
РЕДАКТИРОВАНИЕ
Если вы используете W3C Total Cache, вам следует сделать следующее:
rm -rf wp-content/cache/config
rm -rf wp-content/cache/object
rm -rf wp-content/cache/db
rm -rf wp-content/cache/minify
rm -rf wp-content/cache/page_enhanced
Тогда это сработает!
РЕДАКТИРОВАНИЕ
Через некоторое время при разработке сайтов на WordPress я бы порекомендовал разные разрешения для файлов для каждой среды:
В производственном процессе я бы не давал пользователям доступ к изменению файловой системы, я позволял бы им только загружать ресурсы и предоставлять доступ к некоторым плагинам для определенных папок для создания резервных копий и т.д. Но управление проектами в Git и использование ключей развертывания в сервер, это не хорошие плагины обновления для постановки, ни производства. Я оставляю здесь настройки файла производства:
# Set uploads folder user and group to www-data
chown www-data:www-data -R wp-content/uploads/
www-data: www-data = пользователь и группа apache или nginx
Постановка будет иметь те же производственные разрешения, которые должны быть ее клоном.
Наконец, среда разработки получит доступ к плагинам обновлений, переводам и тому подобному...
# Set uploads folder user and group to www-data
chown www-data:www-data -R wp-content/
# Set uploads folder user and group to www-data
chown your-user:root-group -R wp-content/themes
# Set uploads folder user and group to www-data
chown your-user:root-group -R wp-content/plugins/your-plugin
www-data: www-data = apache или nginx пользователь и группа your-user: root-group = ваш текущий пользователь и корневая группа
Эти разрешения предоставят вам доступ к разработке в папках themes и your-plugin, не спрашивая разрешения. Остальная часть контента будет принадлежать пользователю Apache или Nginx, что позволит WP управлять файловой системой.
Перед созданием git-репо сначала выполните следующие команды:
# Set all directories permissions to 755
find . -type d -exec chmod 755 {} \;
# Set all files permissions to 644
find . -type f -exec chmod 644 {} \;
Правильные разрешения для файла - 644 Правильные разрешения для этой папки - 755
Чтобы изменить разрешения, используйте терминальные и следующие команды.
find foldername -type d -exec chmod 755 {} \;
find foldername -type f -exec chmod 644 {} \;
755 для папок и 644 для файлов.
Фактически это зависит от плагинов, которые вы планируете использовать, поскольку некоторые плагины меняют корневой документ Wordpress. но обычно я рекомендую что-то подобное для каталога wordpress.
Это назначит "root" (или любой другой пользователь, который вы используете) как пользователь в каждом отдельном файле/папке, R означает рекурсивный, поэтому он просто не останавливается в папке "html". если вы не использовали R, то он применим только к каталогу "html".
sudo chown -R root:www-data /var/www/html
Это установит владельца/группу "wp-content" в "www-data" и, таким образом, позволит веб-серверу устанавливать плагины через панель администратора.
chown -R www-data:www-data /var/www/html/wp-content
Это установит разрешение каждого отдельного файла в папке "html" (включая файлы в подкаталогах) на 644, поэтому внешние пользователи не могут выполнить какой-либо файл, изменить любой файл, группа не сможет выполнить какой-либо файл, изменить любой файл, и только пользователю разрешено изменять/читать файлы, но даже пользователь не может выполнить какой-либо файл. Это важно, потому что это предотвращает любое выполнение в папке "html", так как владелец html-папки и всех других папок, кроме папки wp-content, является "root" (или вашим пользователем), www-data может " t изменять любой файл вне папки wp-content, поэтому, даже если на веб-сервере есть какая-либо уязвимость, и если кто-то обратился к сайту неавторизованно, они не могут удалить основной сайт, кроме плагинов.
sudo find /var/www/html -type f -exec chmod 644 {} +
Это ограничит разрешение доступа к "wp-config.php" для пользователя/группы с помощью rw-r ----- этих разрешений.
chmod 640 /var/www/html/wp-config.php
И если плагин или обновление жаловались, что он не может обновить, затем получить доступ к SSH и использовать эту команду и предоставить временное разрешение на "www-data" (веб-сервер) для обновления/установки через панель администратора, а затем вернитесь к "root" или вашему пользователю после его завершения.
chown -R www-data /var/www/html
И в Nginx (такая же процедура для apache), чтобы защитить папку wp-admin от несанкционированного доступа и зондирования. apache2-utils требуется для шифрования пароля, даже если у вас установлен nginx, опустите c, если вы планируете добавить больше пользователей в один и тот же файл.
sudo apt-get install apache2-utils
sudo htpasswd -c /etc/nginx/.htpasswd userName
Теперь зайдите в это место
/etc/nginx/sites-available/
Используйте эти коды для защиты папки "wp-admin" с паролем, теперь он попросит пароль/имя пользователя, если вы попытаетесь получить доступ к "wp-admin". Обратите внимание: здесь вы используете файл .htpasswd, который содержит зашифрованный пароль.
location ^~ /wp-admin {
auth_basic "Restricted";
auth_basic_user_file /etc/nginx/.htpasswd;
index index.php index.html index.htm;
}
Теперь перезапустите nginx.
sudo /etc/init.d/nginx restart
Я думаю, что приведенные ниже правила рекомендуются для сайта Wordpress по умолчанию:
Для папок внутри wp-контента установите разрешения 0755:
chmod -R 0755 плагины
chmod -R 0755 загружает
Обновление chmod -R 0755
Пусть пользователь apache является владельцем указанных выше каталогов wp-контента:
chown apache uploads
обновление chown apache
chown apache plugins
Команды
chown www-data:www-data -R *
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
Где ftp-пользователь - это то, что вы используете для загрузки файлов
chown -R ftp-user:www-data wp-content
chmod -R 775 wp-content
Чтобы убедиться, что ваш сайт защищен, и вы используете правильные разрешения для своих папок, используйте плагин безопасности, подобный этим:
https://en-ca.wordpress.org/plugins/all-in-one-wp-security-and-firewall/
https://en-ca.wordpress.org/plugins/wordfence/
Эти плагины сканируют вашу установку Wordpress и уведомляют вас о любых возможных проблемах. Они также предупреждают вас о каких-либо небезопасных разрешениях на папку. В дополнение к этому, эти плагины будут рекомендовать вам, какие разрешения должны быть назначены папкам.
chown -Rv www-data:www-data
chmod -Rv 0755 wp-includes
chmod -Rv 0755 wp-admin/js
chmod -Rv 0755 wp-content/themes
chmod -Rv 0755 wp-content/plugins
chmod -Rv 0755 wp-admin
chmod -Rv 0755 wp-content
chmod -v 0644 wp-config.php
chmod -v 0644 wp-admin/index.php
chmod -v 0644 .htaccess
Я не могу сказать, правильно ли это или нет, но я использую образ Bitnami над Google Compute App Engine. У меня возникли проблемы с плагинами и миграцией, и после того, как я снова начал разбираться с разрешениями chmod'ing, я нашел эти три строки, которые решили все мои проблемы. Не уверен, правильно ли он работал, но работал на меня.
sudo chown -R bitnami:daemon /opt/bitnami/apps/wordpress/htdocs/
sudo find /opt/bitnami/apps/wordpress/htdocs/ -type f -exec chmod 664 {} \;
sudo find /opt/bitnami/apps/wordpress/htdocs/ -type d -exec chmod 775 {} \;
Для OS X используйте эту команду:
sudo chown -R www:www /www/folder_name
Определите в файле wp_config.
/var/www/html/Your-Project-File/wp-config.php
define( 'FS_METHOD', 'direct' );
chown - изменяет право собственности на файлы/директории. То есть. владелец файла /dir изменяется на указанный, но он не изменяет разрешения.
sudo chown -R www-data:www-data /var/www
Основываясь на прочтении и мучениях на моих сайтах, и после того, как меня взломали, я пришел к приведенному выше списку, который включает разрешения для плагина безопасности для Wordpress под названием Wordfence. (Не связан с этим)
В нашем примере корнем документа WordPress является /var/www/html/example.com/public_html
Откройте права доступа, чтобы www-данные могли записывать в корень документа следующим образом:
cd /var/www/html/example.com
sudo chown -R www-data:www-data public_html/
Теперь с панели инструментов на вашем сайте, как администратор, вы можете выполнять обновления.
Безопасный сайт после завершения обновлений, выполнив следующие действия:
sudo chown -R wp-user:wp-user public_html/
Приведенная выше команда изменяет права доступа ко всему в установке WordPress для пользователя WordPress FTP.
cd public_html/wp-content
sudo chown -R www-data:wp-user wflogs
sudo chown -R www-data:wp-user uploads
Приведенная выше команда гарантирует, что плагин безопасности Wordfence имеет доступ к своим журналам. Каталог загрузки также доступен для записи по www-данным.
cd plugins
sudo chown -R www-data:wp-user wordfence/
Приведенная выше команда также гарантирует, что для плагина безопасности необходим доступ на чтение и запись для правильной работы.
Разрешения для каталогов и файлов
# Set all directories permissions to 755
find . -type d -exec chmod 755 {} \;
# Set all files permissions to 644
find . -type f -exec chmod 644 {} \;
Установите разрешения для wp-config.php равными 640, чтобы только wp-пользователь мог читать этот файл, и никто другой. Разрешения 440 не помогли мне с вышеуказанным владельцем файла.
sudo chmod 640 wp-config.php
Автоматические обновления Wordpress с использованием SSH работали нормально с PHP5, но не работали с PHP7.0 из-за проблем с php7.0-ssh2 bundeld с Ubuntu 16.04, и я не мог найти, как установить правильную версию и заставить ее работать. К счастью, очень надежный плагин под названием ssh-sftp-updater-support (бесплатный) делает возможным автоматическое обновление с использованием SFTP без необходимости в libssh2. Таким образом, приведенные выше разрешения не нужно ослаблять, за исключением редких случаев, когда это необходимо.