Linuxウェブサーバーでウェブサイトのファイル/フォルダーにどのようなアクセス許可を与える必要がありますか？

Question

これは、Linux Webサーバー上のファイル権限についての 標準的な質問 です。

複数のWebサイトをホストするApache2を実行するLinux Webサーバーがあります。各Webサイトには、/ var/www /に独自のフォルダーがあります。

/var/www/contoso.com/
/var/www/contoso.net/
/var/www/fabrikam.com/

ベースディレクトリ/ var/www /はroot：rootが所有しています。 Apacheはwww-data：www-dataとして実行されています。 FabrikamのWebサイトは、2人の開発者、AliceとBobによって管理されています。両方のContoso Webサイトは、1人の開発者Eveによって管理されています。すべてのWebサイトで、ユーザーは画像をアップロードできます。 Webサイトが危険にさらされている場合、影響はできるだけ限定されます。

Apacheがコンテンツを提供でき、Webサイトが攻撃から保護され、開発者が変更を加えることができるように、権限を設定する最良の方法を知りたいです。ウェブサイトの1つは次のように構成されています。

/var/www/fabrikam.com
    /cache
    /modules
    /styles
    /uploads
    /index.php

これらのディレクトリとファイルにアクセス許可をどのように設定する必要がありますか？ Webサイトで777のアクセス許可を使用してはならないことをどこかで読みましたが、何が原因で問題が発生するのかわかりません。繁忙期には、Webサイトは一部のページを自動的にキャッシュし、結果をキャッシュフォルダーに保存します。 Webサイトの訪問者が送信したすべてのコンテンツは、uploadsフォルダーに保存されます。

Answer 1

使用するアクセス許可を決定するときは、ユーザーが誰であり、何が必要かを正確に知る必要があります。ウェブサーバーは2種類のユーザーとやり取りします。

Authenticatedユーザーはサーバー上にユーザーアカウントを持ち、特定の権限を付与できます。これには通常、システム管理者、開発者、サービスアカウントが含まれます。彼らは通常、SSHまたはSFTPを使用してシステムに変更を加えます。

匿名ユーザーはあなたのウェブサイトへの訪問者です。ファイルに直接アクセスする権限はありませんが、Webページを要求することができ、Webサーバーが代わりに機能します。匿名ユーザーのアクセスを制限するには、Webサーバープロセスの権限に注意する必要があります。多くのLinuxディストリビューションでは、Apacheはwww-dataユーザーとして実行されますが、異なる場合もあります。システムでApacheが使用しているユーザーを確認するには、ps aux | grep httpdまたはps aux | grep Apacheを使用します。

---

Linuxパーミッションに関する注意

Linuxおよびその他のPOSIX準拠システムは、従来のUNIX権限を使用します。 Wikipediaには Filesystem permissions に関する優れた記事があるので、ここではすべてを繰り返すことはしません。ただし、注意すべき点がいくつかあります。

実行ビット
解釈されたスクリプト（Ruby、PHPなど）は、実行権限がなくても問題なく機能します。実行ビットが必要なのは、バイナリとシェルスクリプトだけです。ディレクトリを全探索（入力）するには、そのディレクトリに対する実行権限が必要です。ディレクトリを一覧表示したり、ディレクトリ内のファイルを提供したりするには、ウェブサーバーにこの権限が必要です。

デフォルトの新しいファイル権限
通常、ファイルが作成されると、作成者のグループIDを継承します。ただし、新しいファイルが作成されるフォルダーのグループIDを継承するようにしたい場合があるため、親フォルダーのSGIDビットを有効にします。

デフォルトの許可値は、umaskによって異なります。 umaskは新しく作成されたファイルから権限を差し引くので、022の共通の値は755で作成されるファイルになります。グループと共同作業する場合、作成したファイルをグループメンバーが変更できるようにumaskを002に変更すると便利です。アップロードしたファイルの権限をカスタマイズする場合は、Apacheのumaskを変更するか、ファイルのアップロード後にchmodを実行する必要があります。

---

777の問題

あなたがあなたのウェブサイトをchmod 777するとき、あなたは全くセキュリティを持ちません。システム上のすべてのユーザーが、Webサイトのファイルを変更または削除できます。しかし、もっと真剣に、WebサーバーはWebサイトへの訪問者に代わって動作し、Webサーバーは実行中のファイルと同じファイルを変更できることを覚えておいてください。 Webサイトにプログラミングの脆弱性がある場合、それらを利用してWebサイトを改ざんしたり、フィッシング攻撃を挿入したり、知らないうちにサーバーから情報を盗むことができます。

さらに、サーバーが well-known port で実行されている場合（非ルートユーザーが世界中からアクセス可能なリスニングサービスを生成しないようにする必要があります）、つまり、サーバーをルート（ただし、正常なサーバーは、ポートがバインドされるとすぐに、特権の少ないアカウントにドロップされます）。言い換えると、メインの実行可能ファイルがバージョン管理の一部であるWebサーバー（CGIアプリなど）を実行している場合、ユーザーの名前を変更できるため、そのアクセス許可（または、さらに言えば、それを含むディレクトリのアクセス許可）を残します。 777の実行可能ファイル）では、anyユーザーがrootとしてany実行可能ファイルを実行できます。

---

要件を定義する

• 開発者は、Webサイトを更新できるように、ファイルへの読み取り/書き込みアクセスが必要です。
• 開発者は、閲覧できるように、ディレクトリに対する読み取り/書き込み/実行が必要です。
• Apacheはファイルと解釈されたスクリプトへの読み取りアクセスを必要とします
• Apacheはサービス可能なディレクトリへの読み取り/実行アクセスを必要とします
• Apacheはアップロードされたコンテンツのディレクトリへの読み取り/書き込み/実行アクセスを必要とします

---

単一のユーザーが管理

1人のユーザーのみがサイトの保守を担当する場合は、それらをWebサイトディレクトリのユーザー所有者として設定し、ユーザーに完全なrwx権限を付与します。 Apacheはファイルを提供できるようにアクセスを必要とするため、www-dataをグループの所有者として設定し、グループにr-x権限を付与します。

あなたの場合、ユーザー名がeveであるEveが、contoso.comを管理する唯一のユーザーです。

chown -R eve contoso.com/
chgrp -R www-data contoso.com/
chmod -R 750 contoso.com/
chmod g+s contoso.com/
ls -l
drwxr-s--- 2 eve      www-data   4096 Feb  5 22:52 contoso.com

Apacheによる書き込みが必要なフォルダーがある場合は、グループ所有者の権限値を変更するだけで、www-dataに書き込みアクセスが許可されます。

chmod g+w uploads
ls -l
drwxrws--- 2 eve      www-data   4096 Feb  5 22:52 uploads

この設定の利点は、ユーザーとグループの所有者だけがWebサイトディレクトリを参照できるため、システム上の他のユーザーが覗き見するのが難しくなる（しかし不可能ではない*）ことです。これは、構成ファイルに秘密のデータがある場合に役立ちます。 umaskに注意してください！ここで新しいファイルを作成する場合、権限の値はおそらくデフォルトで755になります。umask 027を実行すると、新しいファイルのデフォルトが640（rw- r-- ---）になります。

---

ユーザーのグループが管理

複数のユーザーがサイトの管理を担当している場合は、権限の割り当てに使用するグループを作成する必要があります。 Webサイトごとに個別のグループを作成し、そのWebサイトにちなんでグループに名前を付けることをお勧めします。

groupadd dev-fabrikam
usermod -a -G dev-fabrikam alice
usermod -a -G dev-fabrikam bob

前の例では、グループ所有者を使用してApacheに特権を与えていましたが、今ではそれが開発者グループに使用されています。ユーザーの所有者は私たちにとってもう役に立たないので、rootに設定することは、権限が漏洩しないようにする簡単な方法です。 Apacheはまだアクセスを必要とするので、私たちは他の人に読み取りアクセスを与えます。

chown -R root fabrikam.com
chgrp -R dev-fabrikam fabrikam.com
chmod -R 775 fabrikam.com
chmod g+s fabrikam.com
ls -l
drwxrwxr-x 2 root     dev-fabrikam   4096 Feb  5 22:52 fabrikam.com

Apacheによる書き込みが必要なフォルダーがある場合は、Apacheをユーザー所有者またはグループ所有者にすることができます。どちらの方法でも、必要なすべてのアクセスが可能です。個人的には、私がそれをユーザーオーナーにして、開発者がアップロードフォルダーのコンテンツを閲覧および変更できるようにすることをお勧めします。

chown -R www-data uploads
ls -l
drwxrwxr-x 2 www-data     dev-fabrikam   4096 Feb  5 22:52 uploads

これは一般的なアプローチですが、欠点もあります。システム上の他のすべてのユーザーは、Apacheと同じようにWebサイトに対して同じ権限を持っているため、他のユーザーがサイトを閲覧し、設定ファイルなどの秘密データを含む可能性のあるファイルを読み取るのは簡単です。

ケーキを食べて食べることもできます

これはさらに改善できます。所有者がグループよりも少ない特権を持つことは完全に合法であるため、rootに割り当てることによってユーザー所有者を浪費する代わりに、ApacheをWebサイトのディレクトリおよびファイルのユーザー所有者にすることができます。これは単一のメンテナシナリオの逆ですが、同じようにうまく機能します。

chown -R www-data fabrikam.com
chgrp -R dev-fabrikam fabrikam.com
chmod -R 570 fabrikam.com
chmod g+s fabrikam.com
ls -l
dr-xrwx--- 2 www-data  dev-fabrikam   4096 Feb  5 22:52 fabrikam.com

Apacheによる書き込みが必要なフォルダーがある場合は、www-dataに書き込みアクセスができるように、ユーザー所有者の権限値を変更できます。

chmod u+w uploads
ls -l
drwxrwx--- 2 www-data  dev-fabrikam   4096 Feb  5 22:52 fabrikam.com

このソリューションで注意すべきことの1つは、新しいファイルのユーザー所有者がwww-dataに設定される代わりに作成者と一致することです。したがって、作成した新しいファイルは、chownするまでApacheで読み取ることができません。

---

* Apache権限分離

先に述べたように、実際に使用している特権の種類に関係なく、他のユーザーがWebサイトを覗き見することは可能です。デフォルトでは、すべてのApacheプロセスは同じwww-dataユーザーとして実行されるため、Apacheプロセスは同じサーバー上に構成されている他のすべてのWebサイトからファイルを読み取ることができ、場合によっては変更を加えることもできます。 Apacheにスクリプトを実行させることができるすべてのユーザーは、Apache自体と同じアクセス権を取得できます。

この問題に対処するために、Apacheで 特権の分離 にさまざまなアプローチがあります。ただし、各アプローチには、さまざまなパフォーマンスとセキュリティの欠点があります。私の意見では、セキュリティ要件の高いサイトは、共有サーバーでVirtualHostsを使用するのではなく、専用サーバーで実行する必要があります。

---

追加の考慮事項

以前は触れませんでしたが、通常、開発者がWebサイトを直接編集することは悪い習慣です。大規模なサイトの場合は、バージョン管理システムのコンテンツからWebサーバーを更新する、ある種のリリースシステムを使用することをお勧めします。単一のメンテナアプローチが理想的ですが、人ではなく自動化ソフトウェアを使用しています。

提供する必要のないアップロードがWebサイトで許可されている場合、それらのアップロードはWebルートの外のどこかに保存する必要があります。そうしないと、秘密にされたファイルを人々がダウンロードしていることに気付くでしょう。たとえば、生徒に課題の提出を許可する場合は、Apacheが提供していないディレクトリに保存する必要があります。これは、シークレットを含む構成ファイルの良いアプローチでもあります。

より複雑な要件を持つWebサイトの場合、 アクセス制御リスト の使用を検討することをお勧めします。これらにより、より高度な権限制御が可能になります。

Webサイトに複雑な要件がある場合は、すべての権限を設定するスクリプトを作成することができます。十分にテストしてから、安全に保管してください。何らかの理由でウェブサイトを再構築する必要がある場合は、金の価値に見合う価値があります。

Answer 2

なぜ多くの人がLinuxの権利の「その他」（o）の部分を使用（または推奨）して、Apache（および/またはPHP）で実行できることを制御するのかと思います。この正しい部分を「0」以外の何かに設定することにより、全世界がファイル/ディレクトリに対して何かを実行できるようにするだけです。

私のアプローチは以下の通りです：

• 2つの別々のユーザーを作成します。 1つはすべてのファイルを所有するSSH/SFTPアクセス（必要な場合）、もう1つはPHP FastCGIユーザー（Webサイトを実行するユーザー）です。これらのユーザーをそれぞれ呼び出しましょうbobおよびbob-www。
• bobは完全な権限（rwxはフォルダー、rw-はファイル）を持っているため、Webサイト全体を読み取り、編集できます。
• PHP FastCGIプロセスには、フォルダに対するrx権限とファイルに対するr--権限が必要です。ただし、「書き込み」権限があるcache/またはuploads/などの非常に特定のフォルダは除きます。 PHP FastCGIにこの機能を与えるには、bob-wwwとして実行され、bob-wwwが自動的に作成されたbobに追加されますグループ。
• すべてのディレクトリとファイルの所有者とグループがbob bobであることを確認します。
• 何かが欠けています：FastCGIを使用していますが、Apacheには静的コンテンツの読み取りアクセス権、またはAllowOverrideがNone以外に設定されている場合に読み取りを試みる.htaccessファイルが必要です。権利のo部分の使用を回避するために、www-dataユーザーをbobグループに追加します。

今：

• 開発者ができることを制御するために、権利のuの部分をいじることができます（ただし、これは以下の注記です）。
• ApacheとPHPが実行できることを制御するために、権利のgの部分で遊ぶことができます。
• oの部分は常に0に設定されているため、サーバー上の他の誰もWebサイトを読み取ったり編集したりすることはできません。
• bobユーザーが新しいファイルを作成しても、メイングループ（bob）に自動的に所属するため、問題はありません。

これは要約ですが、この状況では、bobがSSHで許可されます。 Webサイトの変更を許可するユーザーがいない場合（たとえば、顧客はCMS管理パネルを介してのみWebサイトを変更し、Linuxの知識がない場合）、とにかく2人のユーザーを作成しますが、bob-のシェルとして/bin/falseを指定します同様に、そのログインを無効にします。

    adduser --home /var/www/bobwebsite --Shell /bin/bash bob
    adduser --no-create-home --Shell /bin/false --disabled-login --ingroup bob bob-www
    adduser www-data bob
    cd /var/www/bobwebsite
    chown -R bob:bob .
    find -type d -exec chmod 750 {} \;
    find -type f -exec chmod 640 {} \;

注：ファイルの所有者はchmodコマンドを実行できるため、u（所有者）権限を制限することはほとんどの場合無用で安全でないことを忘れがちです権利は000です。

100％確実ではないので、私のアプローチにセキュリティの問題があるかどうかを教えてください。

この設定には問題があると思います。PHP/ Apacheが新しいファイルを作成すると（たとえばアップロード）、bob-www：bobに属し、bobはそれを読み取ることしかできません。ディレクトリのsetuidで問題を解決できるかもしれません。

Answer 3

上記の優れた回答のグーグルランクを考えると、注意すべき点が1つあると思います。回答後にメモを残すことができないようです。

例を続けると、www-dataを所有者として使用し、dev-fabrikamをグループとしてディレクトリ（またはファイル）に570のアクセス権を使用する場合は、Linuxは無視setuidなので、すべての新しいファイルはそれらを作成したユーザーが所有します。つまり、新しいディレクトリとファイルを作成した後、次のようなものを使用する必要があります。

chown -R www-data /newdirectory/
chmod -R 570 /newdirectory/

Rackspace OpenStackのUbuntu 12.04では、サーバーを再起動するまで570の権限を取得できないという奇妙な問題があり、魔法のように問題が修正されました。一見単純そうな問題に比べて、毛を失っていく割合が増えていました...

Answer 4

「leo」というFTPユーザーがファイルをexample.com Webディレクトリにアップロードする必要があり、「Apache」ユーザーがキャッシュディレクトリにuploa-files/sessions/cacheファイルを作成できる必要がある場合は、次のようにします。

このコマンドは、レオを所有者として、グループをApacheとしてexample.comに割り当てます。ApacheユーザーはApacheグループの一部であるため、Apacheグループの権限を継承します

chown -R leo：Apache example.com

正しい許可を保証し、セキュリティの懸念も満たす別のコマンド。

chmod -R 2774 example.com

ここで、最初の番号2はディレクトリ用であり、作成された各新しいファイルが同じグループと所有者の権限に残ることを保証します。 77は所有者およびグループ用であり、フルアクセスが可能です。 4は、他のユーザーがトラフのみを読み取ることができることを意味します。

以下は、許可番号を理解するのに役立ちます

Number  Octal Permission Representation
0   No permission
1   Execute permission
2   Write permission
3   Execute and write permission: 1 (execute) + 2 (write) = 3
4   Read permission
5   Read and execute permission: 4 (read) + 1 (execute) = 5
6   Read and write permission: 4 (read) + 2 (write) = 6
7   All permissions: 4 (read) + 2 (write) + 1 (execute) = 7

Answer 5

私はこの構成で行きます：

1. 所有者rootとグループrootへの1つのセットのアップロード、0755へのアクセス許可を除くすべてのディレクトリ。
2. 所有者rootおよびグループrootに設定されたすべてのファイル、0644への権限。
3. 所有者root、グループwww-data、1770への権限に設定されたディレクトリをアップロードします。スティッキービットでは、グループの所有者は、内部のディレクトリとファイルを削除または名前変更できません。
4. アップロードフォルダー内には、www-dataの所有者ユーザーとグループ、およびファイルをアップロードする各0700ユーザーのwww-data権限を持つ新しいディレクトリがあります。
5. Apacheの設定：

アップロードディレクトリのAllowOverrideとIndexを拒否して、Apacheが.htaccessファイルを読み取らないようにし、Apacheユーザーがアップロードフォルダーのコンテンツにインデックスを付けられないようにします。

<Directory /siteDir>
   Options -Indexes
</Directory>

<Directory /siteDir/uploadDir>
   AllowOverride none
</Directory>

6. php.ini構成：

open_basedir = /siteDir:/tmp:/usr/share/phpmyadmin
post_max_size = 5M
file_uploads = On
upload_max_filesize = 3M
max_file_uploads = 20

この構成では、www-dataユーザーはsiteDir//tmpおよび/usr/share/phpmyadmin以外のディレクトリにアクセスできません。また、同じリクエストでアップロードする最大ファイルサイズ、最大投稿サイズ、最大ファイルを制御することもできます。

Answer 6

IMOは考慮に入れなければなりません：

• ファイルを読み取るプロセスを信頼していますか？例えば。 PHP？

ユーザー「test」の下にさまざまなデータがあるサーバーがあると仮定しましょう。

「テスト」ユーザーはそこにいます：

• $HOMEDIRの彼のデータ
• $MAILでの彼のメール
• /var/www/testの彼のウェブ用データ

次に考えてみましょう：

• webアプリはtestユーザー（PHP-FPM）の下で実行されます-彼のファイルを削除できます！
• webアプリはtestグループ（PHP-FPM）の下で実行されます-ディレクトリのグループが「w」のファイルを削除し、グループが「r」のファイルを変更できます。そして、それはまだそれらを読むことができました-例えばあなたのsshキー！

PHPはバグがあると思いますが、そうです、あなたはそのopen_basedirを信頼していますか？chrootあなたのPHPプロセスですか？あなたは何をしていませんか？すべてのファイルシステムをクロールしますか？

Webアプリのプロセス。 PHP-FPMの場合：

• chrootを介して特定のパスに制限される
• データ所有者のプライマリユーザーまたはプライマリグループの権限で実行しないでください

したがって、次のことができます。

• テストユーザー：test:test
• テストユーザーはセカンダリグループに属しています。 test-www
• webアプリ（PHP-FPM）はtest-www:test-wwwで実行されます
• webアプリがファイルを読み取れるようにしたい場合は、ユーザーをテストします：chmod u=rwX,g=rX,o= /var/www/test/public
• webアプリが自分のWebデータパスに書き込みできるようにする場合は、ユーザーをテストします：chmod u=rwX,g=rwXs,o= /var/www/test/public/upload（したがって、アプリは次のように新しいファイルを作成します：test-www:test-www-上のsetgidによりtest-wwwグループが作成されますディレクトリ！）

したがって、Webアプリプロセスが偽である場合、グループが読み取られる特定のファイルを読み取るだけで、upload dirにのみ書き込むことができます。 upload dirをnoexec,nodev,nosuidmountオプション付きのファイルシステムに設定し、そのディレクトリ内の新しいbizzareファイルを常に監視することを強くお勧めします。さらに、 test-www uid。

Linuxでは、ACLを使用してアクセス許可をより適切に調整できます。複数の人間がWebデータをアップロードする必要がある場合は、Webデータファイルのアップロードに使用されたアカウントから人間のアカウントを分割することをお勧めします。新しいアカウントを作成するなど。 test-upload、テストユーザーはsshキーを管理して、そこにssh/sftpできる人間を制限します。 sshd_configはExposeAuthInfoオプションを認識しているため、データのアップロードに使用されたsshキーをログに記録するように構成できます。

ほとんどのWebホスティングサービスが特権の分離を気にしているとは本当に疑います。