☰

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

tag-icon • tag-icon linux debian security
「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場合は、誰かがコンピュータで実行されているサービスのsshキーをユーザーディレクトリに挿入した可能性が高いので、可能であればユーザーbinログインを完全に無効にしたいと思いますbin。

質問

  • サーバーがリモートで修理費用がかかります（たとえば、リモートユーザーがKVMに接続する費用と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を使用しています。

答え1

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

binほとんどのシステムはコマンドを通常の操作として実行しないため、シェルをbinに設定すること/bin/falseをお勧めします。

bin/bin/.ssh/authorized_keysSSHを介したログインを許可すると、ユーザーまたはrootとしてbinログインする必要があるため、直接的な攻撃のリスクは発生しません。つまり、入ることができる唯一の方法は入ることです。ただし、有効なシェルがあると、設定が正しくないリスクが高くなります。また、SSH 以外のサービスを使用する一部のリモート攻撃も許可されます。レポート攻撃者はSambaを介してリモートでパスワードを設定し、そのdaemonパスワードを使用してSSHを介してログインする可能性があります。

DenyUsersディレクティブにシステム ユーザーの名前を一覧表示することで、SSH の脆弱性を解決できます/etc/ssh/sshd_config(残念ながら、数値範囲は使用できません)。あるいは、逆にAllowGroupsディレクティブを入力し、物理ユーザーを含むグループのみを許可できます（たとえば、usersすべての物理ユーザーにそのグループのメンバーシップを付与する場合など）。

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

答え2

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

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

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

答え3

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

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

つまり、binユーザーは、純粋に伝統の頭をうなずいたり、特定の規格に準拠するために現代のDebian派生物でそれを使用していないようです。

関連情報