「bin」ユーザーにログインシェルが必要なのはなぜですか？

/var/log/auth.logパブリックWebサーバーの1つでの監査中に、これを見つけました。

Jan 10 03:38:11 Bucksnort sshd[3571]: pam_unix(sshd:auth): authentication failure; 
    logname= uid=0 euid=0 tty=ssh ruser= rhost=61.19.255.53  user=bin
Jan 10 03:38:13 Bucksnort sshd[3571]: Failed password for bin from 61.19.255.53 
    port 50647 ssh2

一見したところ、これはsshランダムなハッカーからの典型的なログインスパムのように見えます。しかし、よく見ると何か他のものに気づきました。ほとんどの失敗した/var/log/auth.logエントリはinvalid user、次のようにそれらで言います：

Jan  9 10:45:23 Bucksnort sshd[3006]: Failed password for invalid user sales 
    from 123.212.43.5 port 10552 ssh2

以下のためにその失敗したログインメッセージに関する不穏な事はbin、それがあるということである有効なユーザで/etc/passwdあっても持っているログインシェルは：

[mpenning@Bucksnort ~]$ grep ^bin /etc/passwd
bin:x:2:2:bin:/bin:/bin/sh

で無効にPermitRootLoginしたときにリモートでログインできるすべてのデフォルトのユーザー名をカバーしたと思いました/etc/ssh/sshd_config。このエントリを発見することは、私の妄想心に新しい可能性を開きました。何らかの方法でサービスが実行された場合bin、誰かが何らかの方法でbinボックスで実行中のサービスからユーザーのディレクトリにsshキーを挿入できる可能性があるためbin、可能であればユーザーのログインを完全に無効にしたいと思います。

ご質問

• このサーバーはリモートであり、修正するのに費用がかかります（つまり、KVMを接続するためにリモートの手にお金を払うことになります）。/etc/passwdエントリを次のように変更すると、壊れる可能性があるものを見つけようとしbinています：

  bin:x:2:2:bin:/bin:/bin/false

• 次のコマンドを実行して、何binが必要かを調べました...しかし、これらのコマンドにはファイルがなく、が所有するプロセスは見つかりませんでしたbin。binとにかくユーザーは何をしますか？

  $ sudo find / -group bin

  $ sudo find / -user bin

• ログインシェルを設定する必要がある他のユーザーはいます/bin/falseか？/bin/false参考までに、私はすでに持っていますwww-data。

• 私は妄想しすぎていますか？

それが重要であれば、Debianを実行しています。

有効なシェルを持ち、パスワードを持たないユーザーは、パスワードベースではない方法でログインできます。最も一般的な方法はsshキーです。cronジョブを実行するには、有効なシェルが必要です。動作するには有効なシェルも必要ですsu bin -c 'wibble'（少なくともLinuxでは動作しsu bin -s /bin/sh -c 'wibble'ます）。

の場合bin、ほとんどのシステムはbin通常の操作のようにコマンドを実行しないため、シェルを設定しても/bin/false問題ありません。

ユーザーまたはルートとしてbin作成する必要があるため、SSHを介したログインを許可する直接攻撃のリスクはありません。言い換えれば、侵入する唯一の方法は、侵入することです。しかし、有効なシェルを持っていると、設定ミスのリスクが高まります。また、SSH以外のサービスを使用したリモート攻撃を許可することもできます。たとえば、攻撃者がリモートでSambaを介してパスワードを設定し、そのパスワードを使用してSSH経由でログインできるとユーザーが報告したとします。/bin/.ssh/authorized_keysbindaemon

システムユーザーの名前をDenyUsersディレクティブにリストすることにより、SSHホールを塞ぐことができ/etc/ssh/sshd_configます（残念ながら、数値範囲を使用することはできません）。または、逆に、AllowGroupsディレクティブを入れて、物理ユーザーを含むグループのみを許可することができます（たとえばusers、すべての物理ユーザーにグループメンバーシップを付与する場合）。

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

ユーザーとしてそれらについて心配する必要はありません。セキュリティグループという意味では「ユーザー」であり、「ログインして使用」という意味でのユーザーではありません。"/ etc / shadow"を見ると、これらすべての "ユーザー"にパスワード（長いソルトハッシュではなく "x"または "！"）がないことがわかります。これは、これらのユーザーが何をしてもログインできないことを意味します。

そうは言っても、これらすべてのユーザーの「/ bin / sh」を「/ bin / false」に変更するのが良いかどうかはわかりません。プログラムはこれらのグループの下で実行されるため、必要なコマンドを実行できない場合があります。「/ bin / sh」のままにしておきます。

これらのユーザーについて心配する必要はありません。作成するユーザー（および「/ etc / shadow」にハッシュを持つユーザー）のみを心配する

これは問題ではないと思います。bin'のホームディレクトリ（/bin）にSSH公開キーを設定するためには、攻撃者はファイルシステムへのルートアクセス権を持っている必要があります。

必要にbin応じて、MatchUserブロックを使用してsshdの構成でユーザーのすべての認証方法を無効にすることができます。

そうは言っても、binユーザーは、最近のDebian派生システムでは使用されておらず、純粋に伝統にうなずいている、またはいくつかの標準に準拠するために存在しているように見えます。