私はここを調べましたが、最適なファイル権限の詳細は見つかりませんでした。私もここでWordPressのフォームの質問のいくつかを調べましたが、777を示唆する人は誰でも明らかにセキュリティの少しのレッスンが必要です。
要するに私の質問はこれです。以下に対してどのようなアクセス許可が必要ですか?
- すべてのWordPressコンテンツを格納するルートフォルダー
- wp-admin
- wp-content
- wp-includes
そして、それらの各フォルダ内のすべてのファイル?
私はここを調べましたが、最適なファイル権限の詳細は見つかりませんでした。私もここで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-contentは、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-contentの内容を変更したい場合があります。この場合、あなたは
su
、何をする場合でも、ファイルにwww-dataに対するrw権限があることを確認してください。
www-data
か?これはまったく安全ではないように思えます。
すべてのwpファイルへのフルアクセスをwww-data
ユーザー(この場合はWebサーバーユーザー)に与えることは危険な場合があります。したがって、これを行わないでください。
chown www-data:www-data -R *
ただし、WordPressとそのプラグインをインストールまたはアップグレードするときに役立つ場合があります。しかし、完了したときに、Webサーバーがwpファイルを所有し続けることはもはやお勧めできません。
それは基本的にウェブサーバーがあなたのウェブサイトにどんなファイルでも置くか、または上書きすることを可能にします。これは、誰かがWebサーバー(または.phpスクリプトのセキュリティホール)を使用してWebサイトにファイルを配置した場合、サイトを乗っ取る可能性があることを意味します。
このような攻撃からサイトを保護するには、次のことを行う必要があります。
すべてのファイルはユーザーアカウントが所有し、書き込み可能である必要があります。WordPressからの書き込みアクセスが必要なファイルは、Webサーバーから書き込み可能である必要があります。ホスティングの設定で必要な場合、これらのファイルは、Webサーバープロセスで使用されるユーザーアカウントによってグループ所有される必要がある可能性があります。
/
ルートWordPressディレクトリ:すべてのファイルはユーザーアカウントによってのみ書き込み可能である必要があります。ただし、WordPressが自動的に書き換えルールを生成するようにする場合は.htaccessを除きます。
/wp-admin/
WordPress管理領域:すべてのファイルは、ユーザーアカウントによってのみ書き込み可能である必要があります。
/wp-includes/
WordPressアプリケーションロジックの大部分:すべてのファイルは、ユーザーアカウントによってのみ書き込み可能である必要があります。
/wp-content/
ユーザー提供のコンテンツ:ユーザーアカウントとWebサーバープロセスによる書き込みを目的としています。
内の
/wp-content/
あなたが見つけます:
/wp-content/themes/
テーマファイル。組み込みのテーマエディターを使用する場合は、すべてのファイルがWebサーバープロセスによって書き込み可能である必要があります。組み込みのテーマエディターを使用しない場合は、すべてのファイルをユーザーアカウントでのみ書き込み可能にすることができます。
/wp-content/plugins/
プラグインファイル:すべてのファイルは、ユーザーアカウントによってのみ書き込み可能である必要があります。
存在する可能性のある他のディレクトリ
/wp-content/
は、それらを必要とするプラグインまたはテーマによって文書化する必要があります。権限は異なる場合があります。
ソースおよび追加情報:http : //codex.wordpress.org/Hardening_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のようになります。
追記'could not create directory'
:プラグインの更新中に誰かがエラーに遭遇し
server@user:~/domainame.com$ sudo chown username:www-data -R wp-content
た場合は、ドメインのルートにいるときに行います。
仮定すると:wp-config.php
あり
、ローカルホスト上でFTP証明書を
define('FS_METHOD','direct');
このhttps://wordpress.org/support/article/changing-file-permissions/のワードプレスのドキュメントを読むのが最善です
- すべてのファイルは、httpdプロセスに使用されるユーザーアカウントではなく、実際のユーザーのアカウントが所有する必要があります
- Webサーバープロセスのアクセス許可の確認に関する特定のグループ要件がない限り、グループの所有権は関係ありません。これは通常は当てはまりません。
- すべてのディレクトリは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の特定のユーザーを作成しました。これは、そのユーザーが所有するファイルへのWebからのアクセスを妨げる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
フォルダとフォルダの下での開発にアクセスできます。残りのコンテンツは、WPがファイルシステムを管理できるように、ApacheまたはNginxユーザーが所有します。
git repoを作成する前に、まず次のコマンドを実行します。
# 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。
デフォルトのワードプレスサイトには、以下のルールが推奨されると思います。
wp-content内のフォルダーの場合、0755権限を設定します。
chmod -R 0755プラグイン
chmod -R 0755アップロード
chmod -R 0755アップグレード
上記のwp-contentのディレクトリの所有者をapacheユーザーとします。
chown apacheアップロード
chown apacheアップグレード
chown apacheプラグイン
一部のプラグインはワードプレスのルートドキュメントを変更するため、実際に使用するプラグインによって異なります。しかし、一般的に私はこのようなものをワードプレスディレクトリに推奨します。
これにより、すべてのファイル/フォルダーのユーザーとして「ルート」(または使用しているユーザー)が割り当てられます。Rは再帰を意味するため、「html」フォルダーで停止することはありません。Rを使用しなかった場合は、「html」ディレクトリにのみ適用されます。
sudo chown -R root:www-data /var/www/html
これにより、「wp-content」の所有者/グループが「www-data」に設定され、Webサーバーが管理パネルからプラグインをインストールできるようになります。
chown -R www-data:www-data /var/www/html/wp-content
これにより、「html」フォルダ内のすべてのファイル(サブディレクトリ内のファイルを含む)の権限が644に設定されるため、外部のユーザーはファイルを実行できず、ファイルを変更できず、グループはファイルを実行できず、ファイルを変更できます。ユーザーはファイルの変更/読み取りを許可されていますが、ユーザーでもファイルを実行することはできません。これは「html」フォルダーでのあらゆる種類の実行を防ぐために重要です。また、htmlフォルダーとwp-contentフォルダーを除く他のすべてのフォルダーの所有者が「root」(またはユーザー)であるため、www-dataはt wp-contentフォルダー以外のファイルを変更します。これにより、Webサーバーに脆弱性があり、誰かが不正にサイトにアクセスした場合でも、プラグイン以外のメインサイトを削除することはできません。
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」(Webサーバー)に一時的な許可を与えて、管理パネルからアップデート/インストールしてから、元に戻します。完了したら、「root」またはユーザーに戻ります。
chown -R www-data /var/www/html
Nginx(apacheと同じ手順)では、wp-adminフォルダーを不正アクセスやプローブから保護します。nginxがインストールされている場合でも、パスワードの暗号化にはapache2-utilsが必要です。同じファイルにさらにユーザーを追加する場合は、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-userは、ファイルのアップロードに使用しているユーザーです。
chown -R ftp-user:www-data wp-content
chmod -R 775 wp-content
$(whoami)
代わりに使用できますftp-user
。独自のサーバー(ローカル、vpsなど)を使用している場合、デフォルトでは、現在のユーザー(rootではなく)がFTPユーザーです
あなたのウェブサイトが安全であること、そしてあなたがあなたのフォルダに正しい許可を使用していることを確実にするには、以下のようなセキュリティプラグインを使用してください:
https://en-ca.wordpress.org/plugins/all-in-one-wp-security-and-firewall/
https://en-ca.wordpress.org/plugins/wordfence/
これらのプラグインは、Wordpressインストールをスキャンし、潜在的な問題について通知します。これらは、安全でないフォルダのアクセス許可についても警告します。それに加えて、これらのプラグインは、フォルダにどの権限を割り当てる必要があるかを推奨します。
これが正しいかどうかはわかりませんが、Google Compute App EngineでBitnamiイメージを使用しています。プラグインと移行に問題があり、chmodのアクセス許可をさらに変更した後、これらの3行ですべての問題が解決されたことがわかりました。それが適切な方法であるかどうかはわかりませんが、私にとってはうまくいきました。
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 {} \;
私のサイトでのすべての読書と苦痛に基づいており、ハッキングされた後、Wordfenceと呼ばれるWordpressのセキュリティプラグインの権限を含む上記のリストを思いつきました。(それとは関係ありません)
この例では、ワードプレスのドキュメントルートは/var/www/html/example.com/public_htmlです。
www-dataが次のようにドキュメントルートに書き込むことができるように、権限を開きます。
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-dataでも書き込み可能です。
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-userのみがこのファイルを読み取ることができ、他のユーザーは読み取れないようにします。上記のファイルの所有権では、440の権限が機能しませんでした。
sudo chmod 640 wp-config.php
SSHを使用したWordpressの自動更新はPHP5では問題なく機能しましたが、Ubuntu 16.04にバンドルされているphp7.0-ssh2に問題があるためPHP7.0で機能しなくなり、適切なバージョンをインストールして機能させる方法が見つかりませんでした。幸い、ssh-sftp-updater-support(無料)と呼ばれる非常に信頼性の高いプラグインにより、libssh2を必要とせずにSFTPを使用した自動更新が可能になります。したがって、上記のアクセス許可は、必要に応じてまれな場合を除いて、緩める必要はありません。