Правильные права доступа к файлам для WordPress
Я осмотрел здесь, но не нашел никаких подробностей о лучших файловых разрешений. Я также взглянул на некоторые вопросы формы WordPress над здесь но любой, кто предлагает 777, очевидно, нуждается в небольшом уроке безопасности.
короче, мой вопрос таков. Какие разрешения я должен иметь следующее:
- корневая папка, хранящая все WordPress содержание
- wp-admin
- wp-content
- wp-включает
и тогда все файлы в каждой из этих папок?
15 ответов
при настройке 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-контента, должны быть доступны для записи только вашей учетной записью пользователя. РГ-контент должен быть доступен для записи www-data тоже.
chown <username>:<username> -R * # Let your useraccount be owner
chown www-data:www-data wp-content # Let apache be owner of wp-content
возможно, вы хотите изменить содержимое в wp-контент позже. В этом случае вы могли бы
- временно изменить пользователю на www-data С
su
, - дайте wp-content group write access 775 и присоединяйтесь к группе www-data или
- дать пользователю права доступа к папке с помощью ACLs.
что бы вы ни делали, убедитесь, что файлы имеют разрешения rw для www-data.
предоставление полного доступа ко всем wp-файлам www-data
user (который в данном случае является пользователем веб-сервера) может быть опасным.
Так что лучше сделай не этого:
chown www-data:www-data -R *
это может быть полезно, однако в тот момент, когда вы устанавливаете или обновляете WordPress и его плагины. Но когда вы закончили, это не хорошая идея, чтобы сохранить файлы WP, принадлежащий web-серверу.
это в основном позволяет веб-серверу поставить или перезаписать любой файл в вашем вебсайт. Это означает, что есть возможность взять на свой сайт, если кому-то удастся использовать веб-сервер (или дыру в безопасности, в некоторых .php script), чтобы поместить некоторые файлы на ваш сайт.
чтобы защитить ваш сайт от такой атаки, вы должны сделать следующее:
все файлы должны принадлежать вашей учетной записи пользователя и должны быть доступны для записи от вас. Любой файл, который нуждается в доступе на запись из WordPress, должен быть для записи веб-сервером, если ваш хостинг установить up требует, чтобы может означать, что эти файлы должны принадлежать группе используемой учетной записи пользователя процессом веб-сервера.
/
корневой каталог 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
- добавьте пользователя в группу www-data:
кредит предоставление разрешений на запись в www-data group
нужно позвонить usermod
на ваших пользователей. Так что это будет:
sudo usermod -aG www-data yourUserName
** предполагая, что www-data
группа существует
-
проверьте, что ваш пользователь находится в
www-data
группа:groups yourUserName
вы должны получить что-то вроде:
youUserName : youUserGroupName www-data
* * youUserGroupName обычно похож на you user name
-
рекурсивно измените групповое владение папкой 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)
-
рекурсивно изменить разрешения группы файлов и вложенных файлов, чтобы включить запись permissions:
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'
при обновлении плагина, сделать:server@user:~/domainame.com$ sudo chown username:www-data -R wp-content
когда вы находитесь в корне вашего домена.
Предполагая:wp-config.php
имеет
учетные данные FTP на LocalHostdefine('FS_METHOD','direct');
Я устанавливаю разрешения на:
# 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, вы должны сделать следующее также:
chmod 777 wp-content/w3tc-config
chmod 777 wp-content/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 пользователь и группа
Staging будет иметь те же разрешения на производство, что и его клон.
наконец, среда разработки будет иметь доступ к обновлению плагинов, переводов, всего...
# 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
чтобы изменить разрешения, используйте terminal и следующие команды.
find foldername -type d -exec chmod 755 {} \;
find foldername -type f -exec chmod 644 {} \;
755 для папок и 644 для файлов.
лучше всего прочитать документацию wordpress на этом https://codex.wordpress.org/Changing_File_Permissions
- все файлы должны принадлежать фактической учетной записи пользователя, а не учетной записи пользователя, используемой для процесса httpd
- групповое владение не имеет значения, если нет конкретных требований группы для проверки разрешений процесса веб-сервера. Обычно это не так.
- все папки должны быть 755 или 750.
- все файлы должны быть 644 или 640. Исключение: wp-config.php должен быть 440 или 400, чтобы другие пользователи на сервере не читали его.
- никакие каталоги никогда не должны быть даны 777, даже загружать каталоги. Поскольку процесс php работает как владелец файлов, он получает разрешения владельцев и может писать даже в каталог 755.
Я думаю, что следующие правила рекомендуются для сайта wordpress по умолчанию:
-
для папок внутри wp-контента установите 0755 permissions:
Плагины chmod-R 0755
chmod-R 0755 загрузки
обновление chmod-R 0755
-
пусть пользователь apache будет владельцем вышеуказанных каталогов wp-content:
Чаун Апач загрузка
обновление chown apache
chown Apache Плагины
на самом деле это зависит от плагинов, которые вы планируете использовать, поскольку некоторые плагины изменяют корневой документ 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-данные не могут изменять любой файл за пределами папки 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
команды:
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
Я не могу сказать вам, правильно ли это, но я использую изображение 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 {} \;
чтобы абсолютно убедиться, что ваш сайт безопасен, и вы используете правильные разрешения для своих папок, используйте плагин безопасности, как это:
https://en-ca.wordpress.org/plugins/all-in-one-wp-security-and-firewall/
https://en-ca.wordpress.org/plugins/wordfence/
эти плагины будут сканировать вашу установку Wordpress и уведомлять вас о любых потенциальных проблемах. Они также предупредят вас о любой небезопасной разрешения папки. В дополнение к этому, эти плагины будут рекомендовать вам какие разрешения должны быть отнесены к папкам.
определить в файле wp_config.
/var/www/html/Your-Project-File / wp-config.в PHP
define( 'FS_METHOD', 'direct' );
chown-меняет владельца файлов / dirs. То есть. владелец файла/dir изменяется на указанный, но он не изменяет разрешения.
sudo chown -R www-data:www-data /var/www
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
на основе всех чтения и мучений на моих собственных сайтах и после взлома я придумал приведенный выше список, который включает в себя разрешения для плагина безопасности для Wordpress под названием Wordfence. (Не связан с ним)
в нашем примере корень документа wordpress в /var/www в/HTML-код/пример.на 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 для пользователя FTP wordpress.
cd public_html/wp-content
sudo chown -R www-data:wp-user wflogs
sudo chown -R www-data:wp-user uploads
эта команда гарантирует, что плагин безопасности Wordfence имеет доступ к своим журналам. Каталог uploads также записывается www-data.
cd plugins
sudo chown -R www-data:wp-user wordfence/
эта команда также гарантирует, что плагин безопасности требует доступа на чтение и запись для своей правильной функции.
и разрешения файлов # Установите все разрешения каталогов на 755 находить. - тип 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-поддержка (бесплатно) делает автоматическое обновление с помощью SFTP возможно без необходимости libssh2. Таким образом, вышеуказанные разрешения никогда не должны быть ослаблены, за исключением редких случаев, когда это необходимо.