ログインシェルとしての/ usr / sbin / nologinはセキュリティ目的に役立ちますか？

私には/etc/passwd、ファイル、私がいることがわかりますwww-dataのApacheが使用するユーザーだけでなく、システムのユーザーのすべての種類は、どちらか持っている/usr/sbin/nologinか、/bin/false自分のログインシェルとして。たとえば、次の行を選択します。

daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
games:x:5:60:games:/usr/games:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
syslog:x:101:104::/home/syslog:/bin/false
whoopsie:x:109:116::/nonexistent:/bin/false
mark:x:1000:1000:mark,,,:/home/mark:/bin/bash

そのため、これらのユーザーのいずれかにスワップしようとすると（ユーザーのアクセス許可の理解を確認するためにやりたいことがあり、おそらく他の少なくとも中途の正当な理由があります）、失敗します：

mark@lunchbox:~$ sudo su www-data
This account is currently not available.
mark@lunchbox:~$ sudo su syslog
mark@lunchbox:~$ 

もちろん、次のような方法でシェルを起動できるため、それほど不便ではありません。

mark@lunchbox:~$ sudo -u www-data /bin/bash
www-data@lunchbox:~$ 

しかし、それでは、これらのユーザーにログインシェルを拒否することで、どのような目的が果たされるのかと思うだけです。インターネットで説明を見ると、多くの人がこれがセキュリティに関係していると主張しており、これらのユーザーのログインシェルを変更することは何らかの形で悪い考えであることに誰もが同意するようです。引用符のコレクションは次のとおりです。

Apacheユーザーのシェルを非対話型に設定することは、一般的にセキュリティ上の良い習慣です（対話型でログインする必要のないすべてのサービスユーザーは、シェルを非対話型に設定する必要があります）。

- https://serverfault.com/a/559315/147556

ユーザーwww-dataのシェルは/ usr / sbin / nologinに設定されており、非常に正当な理由で設定されています。

- https://askubuntu.com/a/486661/119754

[システムアカウント] は、特にシェルが有効になっている場合、セキュリティホールになる可能性があります。

• 悪い

  bin:x:1:1:bin:/bin:/bin/sh

• 良い

  bin:x:1:1:bin:/bin:/sbin/nologin

- https://unix.stackexchange.com/a/78996/29001

セキュリティ上の理由から、Tomcatサーバーを実行するためのログインシェルなしでユーザーアカウントを作成しました。

# groupadd tomcat
# useradd -g tomcat -s /usr/sbin/nologin -m -d /home/tomcat tomcat

- http://www.puschitz.com/InstallingTomcat.html

これらの投稿は、システムユーザーに実際のログインシェルを与えないことがセキュリティに良いという満場一致の合意に達していますが、この主張を正当化するものはなく、その説明はどこにもありません。

これらのユーザーに実際のログインシェルを与えないことにより、どのような攻撃から身を守ろうとしていますか？

あなたが見てみましょう場合はnologinmanページは、次の説明が表示されます。

抜粋

nologinは、アカウントが利用できないというメッセージを表示し、ゼロ以外で終了します。これは、アカウントへのログインアクセスを拒否するための代替シェルフィールドとして意図されています。

ファイル/etc/nologin.txtが存在する場合、nologinデフォルトのメッセージの代わりにその内容をユーザーに表示します。

によって返される終了コードnologinは常に1です。

したがって、実際の意図はnologin、ユーザーがアカウントを使用してログインしようとする/etc/passwdと、ユーザーフレンドリーなメッセージが表示され、使用しようとするスクリプト/コマンドがこのログインは終了コード1を受け取ります。

セキュリティ

セキュリティに関しては、通常、その分野の中で/sbin/nologinも/bin/false特に、いずれかまたは時々表示されます。どちらも同じ目的を果たしますが、/sbin/nologinおそらく好ましい方法です。いずれにせよ、彼らはこの特定のユーザーアカウントとしてのシェルへの直接アクセスを制限しています。

なぜこれがセキュリティに関して価値があると考えられますか？

「理由」を完全に説明することは困難ですが、この方法でユーザーのアカウントを制限することの価値は、ユーザーアカウントloginを使用してアクセスしようとすると、アプリケーションを介した直接アクセスを妨害することです。

どちらnologinかを使用するか、/bin/falseこれを達成します。システムの攻撃対象領域を制限することは、特定のポートでサービスを無効にするか、システムのログインの性質を制限するかに関係なく、セキュリティの世界で一般的な手法です。

を使用するための他の合理化がまだありますnologin。たとえばscp、このServerFault Q＆Aタイトル「/ sbin / nologinと/ bin / falseの違いは何ですか？」で説明されているように、実際のシェルを指定しないユーザーアカウントでは動作しなくなります。。

間違いなくセキュリティの目的に役立ちます。たとえば、シェルを使用していたシステムユーザーに対して報告された以下のバグを見てください。

デーモンアカウントが有効なログインシェルを持ち、インターネットアクセス用にsambaを開いているため、私のdebianサーバーが危険にさらされました。侵入は、デーモンアカウントにsambaを介してパスワードをリモートで設定し、sshを介してログインすることによって行われました。その後、ローカルルートエクスプロイトを使用してサーバーを所有しました。

Gillesによるこの素晴らしい回答を読むことをお勧めします。Gillesは、いくつかのバグへのリンクも提供しています。

Debianにはこの問題に関して報告されたバグ（274229、330882、581899）があり、現在は「ウィッシュリスト」として分類されています。これらはバグであることに同意する傾向があり、システムユーザーは、特に必要がない限り、シェルとして/ bin / falseを使用する必要があります。

@slmと@rameshの優れた答えに追加するには：

はい、あなたが指摘したように、sudo定義されたシェルで実行することで、デフォルトのシェルとしてnologinを持つユーザーに切り替えることができますが、この場合、以下を行う必要があります。

1. 有効なシェルを持つ別のユーザーとしてログインします
2. そのユーザーがsuコマンドを実行できるようにsudo許可を構成します。
3. suの試みがsudoersログに記録されていました（もちろんsudoロギングが有効になっていると仮定します）。

デフォルトのシェルとしてnologinが定義されているユーザーは、多くの場合、通常のユーザーよりも高い特権を持っている/システムに多くのダメージを与えることができるため、直接ログインできないと、システムの侵害による被害を制限しようとします。

与えられた優れた答えに加えて、それは別の目的を果たします。

サーバーでFTPデーモンを実行すると、ログインを試みるユーザーのログインシェルがチェックされます。シェルがにリストされ/etc/shellsていない場合、シェルはログインできません。そのため、デーモンアカウントに特別なシェルを与えると、誰かがFTP経由でアカウントを変更することを防ぎます。

すでに与えられた素晴らしい答えの隣に、私は次のシナリオを考えることができます。

制限付きユーザーとして実行されているサービスのセキュリティバグにより、そのユーザーとしてファイルを書き込むことができます。このファイルは〜/ .ssh / authorized_keysです。

これにより、攻撃者はシェルに直接ログインできるようになり、特権エスカレーションの実行がはるかに容易になります。

ログインシェルを許可しないと、このオプションはさらに難しくなります。

一般に、/ bin / falseと/ sbin / nologinは同じだと言いますが、使用しているSSHサーバーに依存すると思います。

OpenSSHのこの最近の悪用が/ bin / falseログインに影響するように見えますが、/ sbin / nologinには影響しないように指摘するのは賢明です。ただし、Dropbearはこの方法で異なると述べています（この脆弱性はOpenSSHにも適用されます）。

エクスプロイトはほとんどのバージョンに影響します：

7.2p1以前（すべてのバージョン、〜20年前）X11転送が有効になっている場合

https://www.exploit-db.com/exploits/39569/

これに基づいて-私は個人的に/ sbin / nologinを実行しますが、これが/ etc / passwdに/ bin / falseエントリを作成するサービスに影響するかどうかはわかりません。実験して結果を確認できますが、自己責任で行ってください。最悪の場合、変更して元に戻し、影響を受けるサービスを再起動できると思います。私は個人的に/ bin / falseを使用してかなりの数のエントリを持っています-X11フォワーディングは私が有効にしたものではないので、これを気にしたいかどうかはわかりません;）

OpenSSHを使用し（多くの人がそう思います...）、X11転送を有効にしている場合、/ sbin / nologinを検討する（またはDropbearに切り替える）ことをお勧めします。

一般に、サービスアカウントとアプリケーションアカウントを非対話型ログインに設定することは、セキュリティ上の良い習慣です。承認されたユーザーは、SUまたはSUDOを使用してこれらのアカウントに引き続きアクセスできますが、そのすべてのアクションはSudoersログファイルで追跡され、サービスアカウント権限でコマンドを実行したユーザーにまでさかのぼることができます。このため、システム管理者がログファイルを変更するためのアクセス権を持たないように、ログファイルを集中ログ管理システムに保存することが重要です。SUまたはSUDOでコマンドを実行するユーザーは、システムへのアクセスを既に許可されています。

一方、システムの外部ユーザーまたは許可されていないユーザーは、これらのアカウントを使用してログインすることはできません。これはセキュリティ対策です。

はい、それはセキュリティ目的に役立ちます。これは、多層防御対策です。

これが目的を果たす主な理由は、指定されたユーザーのログイン資格情報を検証し、そのユーザーのログインシェルを使用してコマンドを実行するさまざまなソフトウェアがあることです。おそらく最も注目すべき例はSSHです。SSH経由でユーザーとして正常に認証されると、SSHはユーザーのログインシェルを起動します（または、ssh someuser@example.com 'command to run'構文を使用する場合は、それを使用して指定したコマンドを実行します）。

もちろん、理想的には、攻撃者がユーザーとして認証されることはまったくありません。しかし、次の状況が発生すると仮定します。

• 制御するサーバーは、ホームディレクトリとログインシェルを持つユーザーとしてWebサービスを実行しています
• 攻撃者は、そのサービスで、攻撃者がユーザーのホームディレクトリにファイルを書き込むことができる脆弱性を発見します。

これで、攻撃者はにSSH公開キーを書き込み~/.ssh/authorized_keys、次にSSH を入力できます-ブーム！-サーバーへのシェルアクセスがあります。

ユーザーが代わりに/usr/sbin/nologinログインシェルとして使用している場合、攻撃者が公開キーをに正常に書き込んだ後でも、ユーザーauthorized_keysにとっては役に立ちません。実行できるのは、リモートで実行することだけnologinです。これはあまり有用ではありません。彼らはシェルを取得できず、攻撃は軽減されました。

このシナリオが非常に仮説的なように思える場合、この質問を行ってから約1年後の2015年のある時点で、まさにこの攻撃の標的にされたことに注意したいと思います。ひどい馬鹿のように、私はRedisのインスタンスを残して、パスワードを公開しませんでした。Redis crackit攻撃の標的になりました。攻撃者は、RedisデータベースにSSH公開キーを挿入し、Redisにデータベースの内容を書き込むように指示するコマンドを送信し、.ssh/authorized_keysSSHを試行します。結果から保存されました。redis-serverAptパッケージのメンテナー（私はRedisをインストールするために使用した）がRedisをRedisとして実行するための知恵を持っていたという事実によってのみ、私自身の無能さのredisホームディレクトリまたはログインシェルを持たないユーザー。それらがなければ、私のサーバーはおそらくランサムウェアであるか、ハッカーのボットネットの一部になっていたでしょう。

この経験により、ある程度の謙虚さが得られ、多層防御の重要性、特にWebサーバー、データベース、その他のバックグラウンドサービスを実行するアカウントにログインシェルを許可しないことの重要性を認識しました。