Правильные права доступа к файлам для WordPress

Я осмотрел здесь, но не нашел никаких подробностей о лучших файловых разрешений. Я также взглянул на некоторые вопросы формы WordPress над здесь но любой, кто предлагает 777, очевидно, нуждается в небольшом уроке безопасности.

короче, мой вопрос таков. Какие разрешения я должен иметь следующее:

  1. корневая папка, хранящая все WordPress содержание
  2. wp-admin
  3. wp-content
  4. 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

  1. добавьте пользователя в группу www-data:

кредит предоставление разрешений на запись в www-data group

нужно позвонить usermod на ваших пользователей. Так что это будет:

sudo usermod -aG www-data yourUserName

** предполагая, что www-data группа существует

  1. проверьте, что ваш пользователь находится в www-data группа:

    groups yourUserName

вы должны получить что-то вроде:

youUserName : youUserGroupName www-data

* * youUserGroupName обычно похож на you user name

  1. рекурсивно измените групповое владение папкой wp-content, сохраняя право собственности пользователя

    chown yourUserName:www-data -R youWebSiteFolder/wp-content/*

  2. каталог youWebSiteFolder / wp-content/

    cd youWebSiteFolder/wp-content

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

    find . -type d -exec chmod -R 775 {} \;

** режим ` / home / yourUserName/youWebSiteFolder / wp-content/ ' изменен с 0755 (rwxr-xr-x) на 0775 (rwxrwxr-x)

  1. рекурсивно изменить разрешения группы файлов и вложенных файлов, чтобы включить запись 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' при обновлении плагина, сделать:
[email protected]:~/domainame.com$ sudo chown username:www-data -R wp-content
когда вы находитесь в корне вашего домена.
Предполагая:wp-config.php имеет
учетные данные FTP на LocalHost
define('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 {} \;

для OS X Используйте эту команду:

sudo chown -R www:www /www/folder_name

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

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. Таким образом, вышеуказанные разрешения никогда не должны быть ослаблены, за исключением редких случаев, когда это необходимо.