web-dev-qa-db-ja.com

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

私の公開Webサーバーの1つでの/var/log/auth.logの監査中に、次のことがわかりました。

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

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

ご質問

  • このサーバーはリモートであり、修正に費用がかかります（つまり、KVMを接続するためにリモートの手にお金を払います。さらに、KVMレンタル）。変更した場合、何が壊れるかを理解しようとしています。 binの/etc/passwdエントリは、次のようになります。

    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を実行しています。

linuxdebiansecurity
27
Mike Pennington

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

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

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

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

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

22
Gilles 'SO- stop being evil'

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

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

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

6
Chris

SSH公開キーをbinのホームディレクトリ（/bin）、攻撃者はファイルシステムへのrootアクセス権を持っている必要があります。

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

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

1
user21217