web-dev-qa-db-ja.com

nginxがrootとしてプロセスを開始するのはなぜですか？

Nginxサーバーをインストールしました。リスニングポートを確認したところ、次のことがわかりました。

$ Sudo lsof -nP -i | grep LISTEN
sshd       614     root    3u  IPv4   7712      0t0  TCP *:22 (LISTEN)
nginx      822     root    7u  IPv4   8745      0t0  TCP *:80 (LISTEN)
nginx      827 www-data    7u  IPv4   8745      0t0  TCP *:80 (LISTEN)
nginx      828 www-data    7u  IPv4   8745      0t0  TCP *:80 (LISTEN)
nginx      829 www-data    7u  IPv4   8745      0t0  TCP *:80 (LISTEN)
nginx      830 www-data    7u  IPv4   8745      0t0  TCP *:80 (LISTEN)
.
.
.

そして、なぜ私は「www-data」ユーザーとして実行されている4つのnginxプロセスと「rootユーザー」として実行されている1つのnginxプロセスがあるのか​​興味がありますか？

nginx
39
Erik

気づいたプロセスはマスタープロセスであり、他のすべてのnginxプロセスを開始するプロセスです。このプロセスは、nginxを起動するinitスクリプトによって開始されます。このプロセスがrootとして実行されている理由は、単にrootとして開始したためです！別のユーザーとして起動することもできますが、nginxが必要とするすべてのリソースをこのユーザーが利用できることを確認する必要があります。通常は、少なくとも/ var/log/nginxと/ var/run /の下のpid-fileです。

最も重要なこと;ルートプロセスのみが1024未満のポートをリッスンできます。Webサーバーは通常、ポート80または443、あるいはその両方で実行されます。つまり、ルートとして起動する必要があります。

結論として、ルートによって実行されるマスタープロセスは完全に正常であり、ほとんどの場合、通常の操作に必要です。

編集：ルートとして何かを実行すると、暗黙のセキュリティリスクが発生します。通常、この種のソフトウェアの開発者は、攻撃ベクトルについて多くの知識を持ち、ルートとしてできるだけ実行しないように細心の注意を払います。結局のところ、ソフトウェアが高品質であることを信頼する必要があります。

それでも不安を感じる場合は、nginxを別のユーザーとして実行し、1024未満のポートを使用する方法があります。iptablesを使用して、ポート80のすべての着信トラフィックを別のポート（例：8080）にリダイレクトし、nginxにそのポートをリッスンさせることができます。

50
arnefm

ほとんどのサーバー（Apache、Nginxなど）にはrootが所有する親プロセスがあり、資格情報の少ないユーザーを使用してワーカーノードのコピーをフォークします。この場合はwww-data。

例

nginxの設定ファイルを見ると、/etc/nginx/nginx.conf、このような行に気づくでしょう：

user nginx;
worker_processes 2; #change to the number of your CPUs/Cores
worker_rlimit_nofile 8192;

ほとんどのサーバーには、これと同様のオプションがあり、スレーブノードを実行するユーザーとその数を指定します。

安全保障

Rootアクセスを持つサービスを公開することは、潜在的な不安としてしばしば言及されます。ただし、1から1024の範囲のポートにバインドするにはrootである必要があることが多いため、サーバーがポート80または443でリッスンするようにしたい場合、実際にできることはありません。

また、サービスが適切に記述され、適切に構成されている場合、それ自体が必ずしもセキュリティ体制に有害であるとは限りません。 Apache＆Nginxの上で実行されるアプリケーションは、サーバースタックに注入される不正なデータのエントリポイントを公開するサービスであるため、実際にはバッファオーバーフローまたはSQLサーバーインジェクション攻撃の真の発生源です。

ApacheとNginx自体は、一般に、受け入れているGET/POSTメソッド以外の入力を受け入れません。

17
slm

これがアプリケーションのパッケージ方法です。ほとんどの* nixでは、デフォルトのセットアップは非特権ユーザーは1024未満のポートでリッスンできず、Webサーバーは80および443を使用します。

Linux 2.2以降、Solaris 10以降、およびFreeBSDのすべてでは、デフォルトではなく、ルート以外のユーザーが1024未満のポートでリッスンすることができます。ほとんどの人がrootの使用を受け入れているので、引き続き使用されています。

特権ポートにバインドするアクセス以外に、nginxを実行しているユーザーが必要なすべてのファイルにアクセスできることを確認する必要があります。あなたはおそらく これまで行く必要はありません ですが、ファイル/ディレクトリに正しい許可を設定するだけです。また、スタートアップスクリプトがulimitの変更などの卑劣な処理を行わないことも確認する必要があります（mysqlは常にそうです）。

Linux機能

setcap および getcap 実行可能ファイルのcap_net_bind_service機能を変更または表示できます。これは、バイナリを実行するすべての人に有効です。

setcap cap_net_bind_service=+ep /usr/sbin/nginx

SELinuxは、ユーザーレベルで機能を構成および制御する機能を提供します。

Freebsdシステム設定

予約済みポート設定はシステム全体に適用されます

sysctl net.inet.ip.portrange.reservedhigh=0
sysctl net.inet.ip.portrange.reservedlow=0

Solaris特権

Solarisは、ユーザーレベルで権限をきめ細かく制御できます。これらはApacheの権限ですが、nginxでも機能する可能性があります。

/usr/sbin/usermod -K defaultpriv=basic,proc_exec,proc_fork,net_privaddr nginx
6
Matt

皆さんの答えを追加したいと思います。 nginxはrootとして起動されますが、実際にはrootとして実行されていません。実際に実行されているユーザー（nginx、www-dataなど）は、通常、制限付き/投獄されたログインです（これでログインすることはできず、特定のファイルのみにアクセスできます）。これは、Windowsとは対照的に、WebサーバーにLinuxを使用することの利点の1つです。このプロセスはfork（ このWikipediaの記事で詳細を確認できます ）と呼ばれ、setuidやsetgid（- Wikipediaの記事でも説明されています ）ユーザーやグループを変更します。安全な設定では、ハッカーは親プロセスにアクセスできず、ルートアカウントを利用できません。ハッカーがルートアクセスを取得するためにある種のエクスプロイトを利用する可能性があるため、これは常に当てはまるわけではありません（nginx 1.4.0以前には、ハッカーがルートアクセスを取得できる脆弱性がありました）。

2
ub3rst4r