web-dev-qa-db-ja.com

Nginxの仮想ホストごとのユーザー

Nginxで仮想ホストごとに異なるユーザーを構成することは可能ですか？

何かのようなもの

 server {
     user myprojectuser myprojectgroup;
     ...
 }
securitynginx
31
Alex Netkachov

いいえ。nginx構成のすべてのサーバースタンザは、同じワーカープロセスのセットから提供されるためです。さらに、セキュリティの観点から見ると、そのように実行するのはbetterです。これは、コンテンツがWebサーバーによって自動的に書き込めない（chmod -R 0777のような愚かさがない）ことを意味します。 nginxに脆弱性がある場合、危険にさらされるコンテンツはありません。

7
womble

はい。これは可能であり、セキュリティを強化するために推奨されます（以下の理由を参照してください）。

PHP-FPMを使用していることを考えると（おそらく最も一般的ですが）、ドメインごとに異なるユーザーが所有するスプールを作成できます。

PS：詳細な手順を追ったチュートリアルをここに書きました：

https://learnwithdaniel.com/2019/06/user-per-virtual-Host-nginx/

1.スプールを作成します：

スプールを/etc/php/7.0/fpm/pool.d/www.confに追加するか、新しいスプールごとに新しい.confファイルを作成します。

スプール＃1（myuser1）：

[myprojectuser1]
user = myuser1
group = myprojectgroup
..
listen = /run/php/myuser1.sock
...  
listen.owner = www-data
listen.group = www-data

スプール＃2（myuser2）：

[myprojectuser2]
user = myuser2
group = myprojectgroup
..
listen = /run/php/myuser2.sock
...  
listen.owner = www-data
listen.group = www-data

PS：listen.owner/listen.groupを同じnginxユーザーに保持します（通常www-data）。

2.各スプールをサーバーブロックに割り当てます（Apacheユーザーの仮想ホスト）：

ホスト1：

server {
  ...
  location ~ \.php$ {
    fastcgi_pass unix:/run/php/myuser1.sock;
  }
  ...
}

ホスト2：

server {
  ...
  location ~ \.php$ {
    fastcgi_pass unix:/run/php/myuser2.sock;
  }
  ...
}

FPMおよびNGINXサービスを再起動します

Sudo /etc/init.d/php7.0-fpm restart
Sudo service nginx restart

テスト：

現在のプロセスユーザーを表示するpinfo.php（または任意の名前）ファイルを作成します。

<?php 
echo str_replace("\n", '<br>', Shell_exec('ps -u -p '.getmypid()));

または、bashでpinfo.phpファイルを作成します。

echo "<?php echo str_replace(\"\\n\", '<br>', Shell_exec('ps -u -p '.getmypid()));" > pinfo.php

次に、ブラウザで " http：//.../pinfo.php "を開きます。

複数のユーザーを使用する理由（セキュリティ上の理由）：

すべてのWebサイトを同じユーザー（www-data）で実行している場合、system（）/ passthru（）/ exec（）へのPHP呼び出しはすべてのWebサイトにアクセスできます！ NGINXはこれからあなたを保護しません。 PHPは単なる例ですが、人気のあるWebサーバー言語はどれも同様の呼び出しを持っています。ハッカーは、「ls .. "を使用してすべてのWebサイトをナビゲートしたり、" cp/echo/mv "を使用して任意のファイル（別のWebサイトを含む）に独自のコードを記述したりできます。ファイル）。サーバー上のすべてのWebサイトが同じユーザー（例：あなた）によって所有されている場合でも、ハッカー/ウイルス（例：Wordpressウイルス）を防ぐため、各ユーザーを別のユーザーで実行することをお勧めします。他のウェブサイトへのアクセス。

11
Daniel Loureiro

上記のIvanのコメントへの応答で、OPに適用できるようです。 2つのこと：

  1. アプリケーションのドキュメントルートは、/blah/peterWeb/htmlや/blah/johnWeb/htmlのようになります。 NGINXとApache2はどちらもwww-dataをグループとして実行している場合でも、他のディレクトリを閲覧したり操作したりすることはできません。

  2. 各ディレクトリツリーを独自のユーザー権限の下に配置すると、各ユーザーがUNIXシステムにssh /ログインして、それぞれのディレクトリをプライベートに保つことができます。各ユーザーをwww-dataグループに入れないでください。あなたが同意した場合、あなたの文は：

    PHPスクリプトまたはcgi-binプロセスを提供できるすべてのユーザーは、www-dataユーザーがアクセスできるすべてのファイルにアクセスできます。

    より正確には次のようになります。

    apache/nginxサーバー（www-data）と同じグループに入れたすべてのユーザーは、アクセス可能な任意のファイル（phpスクリプトの実行を含む）で好きなことを実行できます（これは基本的にWeb上のすべてです）サーバ）。

EDIT 1：サーバー管理者の問題に対処する必要があるため、このトピックをさらに詳しく調べました。私はイヴァンの情報がどれほど正確であるか知りませんでした！共有ホスティング構成でスクリプトをアップロードして実行する機能をユーザーに提供する場合は、注意が必要です。これが 1つのアプローチ です。この脆弱性を確実に理解したことを確認するためのIvanへの帽子のヒント。

5
Ricalsin