☰

为什么“bin”用户需要登录 shell？

tag-icon • tag-icon linux debian security
为什么“bin”用户需要登录 shell？

/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甚至有一个登录 shell：

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

PermitRootLogin我以为我已经涵盖了禁用时可以远程登录的所有默认用户名/etc/ssh/sshd_config；发现这个条目在我偏执的头脑中开启了新的可能性。如果以某种方式服务在 下运行bin，那么有人很可能以某种方式bin从机器上正在运行的服务将 ssh 密钥插入到用户的目录中，所以如果可能的话，我想完全禁用用户的登录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

  • 是否还有其他用户应该将其登录 shell 设置为/bin/false？仅供参考，我已经/bin/false有了www-data。

  • 我是不是太偏执了？

我正在运行 Debian，如果这很重要的话。

答案1

拥有有效 shell 且没有密码的用户仍然可以通过非基于密码的方法登录，最常见的是 ssh 密钥。运行 cron 作业需要有效的 shell。有效的 shell 也是su bin -c 'wibble'工作所必需的（至少在 Linux 上su bin -s /bin/sh -c 'wibble'也可以工作）。

在 的情况下bin，大多数系统不会像正常操作那样运行命令bin，因此将 shell 设置为/bin/false就可以了。

bin允许通过 SSH 登录不存在任何直接攻击的风险，因为这需要/bin/.ssh/authorized_keys以用户bin或 root 身份进行创建。换句话说，进入的唯一方法就是进入。但是，拥有有效的 shell 确实会增加错误配置的风险。它还允许使用 SSH 以外的服务进行一些远程攻击；例如一个用户报告攻击者可以通过 Samba 远程设置密码daemon，然后使用该密码通过 SSH 登录。

DenyUsers您可以通过在中的指令中列出系统用户的名称来堵住 SSH 漏洞/etc/ssh/sshd_config（不幸的是，您不能使用数字范围）。或者，相反，您可以放置​​一个AllowGroups指令并仅允许包含物理用户的组（例如，users如果您向所有物理用户授予该组成员身份）。

Debian 中存在关于此问题的错误（#274229,#330882,#581899），目前开放并分类为“愿望清单”。我倾向于同意这些都是错误，系统用户应该将其/bin/false作为他们的 shell，除非看起来有必要这样做。

答案2

作为用户，您不必担心这些。他们是安全群体意义上的“用户”，而不是“登录和使用”人意义上的用户。如果您查看“/etc/shadow”，您将看到所有这些“用户”都没有密码（“x”或“！”而不是长盐哈希）。这意味着这些用户无论如何都无法登录。

也就是说，我不知道对于所有这些用户将“/bin/sh”更改为“/bin/false”是否是一个好主意。由于程序在这些组下运行，因此可能不允许它们执行所需的命令。我将它们保留为“/bin/sh”。

您无需担心这些用户。只需担心您创建的用户（以及“/etc/shadow”中具有哈希值的用户）

答案3

我相信这不是问题，因为为了在bin的主目录 ( /bin) 中设置 SSH 公钥，攻击者必须拥有文件系统的 root 访问权限，这意味着无论如何你都被搞砸了。

如果您愿意，您可以bin使用该块在 sshd 配置中禁用用户的所有身份验证方法MatchUser。

也就是说，看起来 bin 用户在现代 Debian 派生系统上未使用，纯粹是对传统的认可，或者是为了遵守某些标准。

相关内容