web-dev-qa-db-ja.com

サービスアカウントのデフォルトシェルを変更するための推奨事項

ほとんどのLinuxシステムでは、サービスアカウントのデフォルトシェルとして/sbin/nologinまたは/bin/falseを使用しているようです。 CISベンチマークなどの多くの強化ガイドでは、これらのアカウントのデフォルトのシェルを/dev/nullに変更することを推奨しています。多くの推奨事項に分析が添付されていますが、これは私が正当化したことを一度も見たことがないものです。この推奨事項を推進しているのはどのような懸念であり、緩和しようとしている脅威は何ですか?

14
Scott Pack

私が知っている唯一の真の技術的な理由は、悪意のあるファイルの置換の可能性です。任意のファイルに書き込む方法を見つけた攻撃者を考えます。/sbin/nologinまたは/ bin/falseを/ bin/bashのコピーで上書きできる場合、サービスユーザーとしてログインし、そこから引き続き特権を昇格させる方法を見つけることができます。

ただし、/ dev/nullは、さまざまな理由により、このような方法で簡単に置き換えることはできません。

  • フラットファイルではなくデバイスです
  • 書き込まれたものはすべて消えるので、単純な上書きは機能しません
  • 誰かがそれを/ bin/bashに置き換えた場合、次に、/ dev/nullをビットシンクとして使用する多くのプログラムの1つによって上書きされ、攻撃者を阻止する可能性があります。
  • 誰かがそれを置き換えた場合、システムの一部の機能が破壊され、管理者に何かが間違っていることが警告される可能性があります。「nologin」や「false」を置き換えるよりもはるかに重要です。

非技術的な理由もあります。これは、多くの管理者が昔から学んだ伝統や習慣に縛られているためです。/dev/nullは、この使用法のより一般的な選択でした(/ sbinは確かです)/nologinは20年前には存在しませんでした)。あなたがそうするものを作りなさい。

14
gowenfawr

すばらしい質問です。私の知る限り、このアドバイスは正当化されません。私の知る限り、それは悪いアドバイスです。 /bin/falseまたは/sbin/nologinで結構です。 (何かを見逃した場合は、見落としていることを知りたいと思います。)

4
D.W.

私はLinuxの第一人者ではありませんが、これをWindowsのサービスアカウントの推奨事項と比較すると、対話型ログオンの可能性を含め、すべての特権を削除することに相当すると思います。
これはおそらく、攻撃対象領域/最小限の特権を最小限に抑える問題です...:

必要なければ、電源を切ってください。

4
AviD

/ dev/nullを使用すると、不正な対話型シェルログイン試行のセキュリティ監査ログが生成されません。

3
Rodney Beede