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

在/var/log/auth.log对我的一个公共Web服务器进行审核时，我发现：

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。

linux debian security

— 迈克·彭宁顿
source

一个相关的问题是unix.stackexchange.com/questions/485505。

— JdeBP '18年

Answers:

具有有效外壳程序且没有密码的用户仍可以通过基于非密码的方法登录，最常见的是ssh密钥。有效的shell是运行cron作业所必需的。有效的外壳对于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 用户身份进行创建。换句话说，进入的唯一方法是进入。但是，拥有有效的外壳确实会增加配置错误的风险。它还可以允许使用SSH以外的服务进行某些远程攻击；例如，用户报告攻击者可以daemon通过Samba远程设置密码，然后使用该密码通过SSH登录。

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

Debian（＃274229，＃330882，＃581899）中存在有关此问题的错误，目前已打开并归类为“ 收藏夹 ”。我倾向于同意这些是bug，/bin/false除非看起来有必要这样做，否则系统用户应将其作为shell。

— 吉尔斯“别再邪恶了”
source

作为用户，您不必担心这些。从安全组的角度来看，它们是“用户”，从“登录和使用”人员的角度而言，它们不是用户。如果查看“ / etc / shadow”，将会看到所有这些“用户”都没有密码（“ x”或“！”而不是冗长的哈希值）。这意味着这些用户无论如何都无法登录。

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

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

— 克里斯
source

关于没有哈希的公平点/etc/shadow，但是如果服务以用户身份运行，则理论上有人可以插入ssh登录键，对吗？

— Mike Pennington

仅当他们已经以root用户特权登录到您的帐户时...在这种情况下，这些用户才是您的后顾之忧：-P

— Chris

我不确定我是否同意您刚才列出的所有限制。如果这是真的，那么打开rpcd端口就不会有问题。但是，我亲眼目睹了在旧Solaris机器上进行远程利用的结果，攻击者通过rpc盒子上的利用漏洞获得了访问权限。 rhosts已由该rpc用户启用和写入（不记得更多的详细信息……那是几年前的事了）……同样，如果他们可以~/.ssh/authorized_keys为可以登录的用户创建一个，那么这似乎仍然是一种风险（即使没有中的密码/etc/shadow）

— Mike Pennington 2012年

是的，但是这种利用不是通过SSH进行的。程序通常在自己的用户下运行（如您所说）。程序中的漏洞（例如，缓冲区溢出漏洞）可以使恶意用户访问该程序有权访问的外壳。但是，该程序需要访问权限才能执行该程序要执行的操作（否则，它无法访问其需要执行的操作）。这就是确保正确设置权限很重要的原因。rpc守护程序中的漏洞利用是一个很大的问题，可以通过更新软件（或对其进行限制）来解决。

— 克里斯

抱歉，没房间了。更改程序可以访问的外壳确实可以解决该问题，但是这会使程序实际应该执行的操作产生更多问题。我以为您最初的意思是恶意用户可以通过该用户进行SSH，但他们不能这样做（除非您相信，除非他们设置了密钥）。您可以通过在sshd_config中放入“ AllowUsers <用户名> <用户名> ...”以仅允许特定用户SSH访问来解决该小问题。

— 克里斯

我相信这不是问题，因为为了在起始bin目录（/bin）中设置SSH公钥，攻击者必须具有对文件系统的root访问权，这意味着您无论如何都要搞砸了。

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

话虽如此，看来bin用户在现代Debian衍生的系统上未使用过，纯粹是对传统的致敬或符合某些标准。

— 用户名
source