私の/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
これらの投稿は、システムユーザーに実際のログインシェルを提供しないことはセキュリティに良いことであるという満場一致の合意にありますが、それらの1つがこの主張を正当化するものではなく、どこにも説明はありません。
これらのユーザーに実際のログインシェルを与えないことによって、どのような攻撃から身を守ろうとしていますか?
nologin
のmanページを見ると、次の説明が表示されます。
抜粋
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? 。
間違いなく、それはセキュリティの目的を果たします。たとえば、以下のシェルを持っているシステムユーザーのファイル bug を見てください。
デーモンアカウントに有効なログインシェルがあり、インターネットアクセス用にsambaが開いているため、debianサーバーが危険にさらされました。侵入は、デーモンアカウントのsambaを介してリモートでパスワードを設定し、sshを介してログインすることで行われました。その後、ローカルルートエクスプロイトがサーバーを所有するために使用されました。
この素晴らしい answer を読み、いくつかのバグへのリンクを提供してくれたGillesもお勧めします。
Debianにはこの問題に関して提出されたバグがあり(274229、330882、581899)、現在オープンしていて、「ウィッシュリスト」に分類されています。これらはバグであり、システムユーザーは特に必要がない限り、シェルとして/ bin/falseを設定する必要があることに同意する傾向があります。
@slmと@rameshの優れた回答に追加するには:
はい、指摘したように、シェルを定義してSudo
を実行することにより、デフォルトのシェルとしてnologinを使用するユーザーに切り替えることができますが、この場合は次のようにする必要があります。
su
コマンドを実行するためのSudo権限を構成している。デフォルトのシェルとして定義されているnologinを持つユーザーは、通常よりも高い特権を持っているか、通常のユーザーよりもシステムに多くの損害を与えることができるため、直接ログインできないようにすることで、システムの侵害が被る可能性がある損害を制限しようとします。
すでに与えられたすばらしい答えの隣に、私は次のシナリオを考えることができます。
制限付きユーザーとして実行されているサービスのセキュリティバグにより、そのユーザーとしてファイルを書き込むことができます。このファイルは〜/ .ssh/authorized_keysにすることができます。
これにより、攻撃者はシェルに直接ログインできるため、特権の昇格をより簡単に実行できます。
ログインシェルを禁止すると、このオプションはさらに難しくなります。
与えられた優れた答えに加えて、それは別の目的を果たします。
サーバーでFTPデーモンを実行すると、ログインを試みるユーザーのログインシェルがチェックされます。シェルが/etc/shells
にリストされていない場合は、ログインできません。したがって、デーモンアカウントに特別なシェルを与えると、誰かがFTP経由でアカウントを変更できなくなります。
一般的には/ 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 [email protected] 'command to run'
構文を使用している場合は、それを使用して指定したコマンドを実行します)。
もちろん、理想的には、攻撃者はユーザーとして認証することができません。ただし、次の状況が発生したとします。
これで、攻撃者はSSH公開鍵を~/.ssh/authorized_keys
に書き込んでから、SSHを使用して-ブームできます! -彼らはあなたのサーバーへのシェルアクセスを持っています。
代わりに、ユーザーがログインシェルとして/usr/sbin/nologin
を持っている場合、攻撃者がauthorized_keys
に公開鍵を正常に書き込んだ後でも、ユーザーにとっては役に立ちません。これにより、リモートでnologin
を実行するだけで、あまり役に立ちません。彼らはシェルを入手できず、彼らの攻撃は軽減されました。
このシナリオが非常に架空であると思われる場合は、2015年のある時点、約1年後、この攻撃の対象となった正確にことを指摘しておきます私はこの質問をしました。ばかげたばかのように、私はRedisインスタンスをパスワードなしで世界中に公開しました。 Redis crackit 攻撃の標的になり、攻撃者はSSH公開鍵をRedisデータベースに挿入し、データベースの内容を.ssh/authorized_keys
に書き込むようにRedisに指示するコマンドを送信します。次に、SSHでログインしようとします。redis-server
Aptパッケージ(Redisのインストールに使用していた)のメンテナーがRedisを実行する知恵を持っているという事実によってのみ、私は自分の無能の結果から救われましたホームディレクトリまたはログインシェルを持たないredis
ユーザーとして。それがなかったとしたら、私のサーバーはランサムウェア化されているか、ハッカーのボットネットの一部になっている可能性があります。
その経験は私にある程度の謙虚さを与え、そして defence in depth の重要性、そして特に、ウェブサーバー、データベース、および他のバックグラウンドサービスを実行するアカウントにログインシェルを許可しないことの重要性を認めました。